Decide when a one-request upload is enough and when recovery matters.
Match the protocol to the file
For small images on stable connections, a direct single-request upload is simple. For long videos or mobile networks, a failed request should not force the user to resend the entire file. A resumable protocol tracks an upload identifier and the committed byte offset so the client can continue from a known point.
Persist state on both sides
The server must bind the upload session to a user, expected size, expiration, and destination. The client should save the upload ID and query the server’s current offset after reconnecting instead of trusting its local counter. Progress means bytes accepted by the server, not just bytes sent by the browser.
Finish exactly once
After the final chunk, verify length and checksum, then create or finalize one asset record. Expire incomplete uploads and reclaim their storage. Test interrupted requests, duplicate chunks, browser refreshes, and two tabs resuming the same session before relying on the happy path.
A concrete acceptance test
Interrupt a large upload halfway, restart the browser, and resume from the server-reported offset. Repeat the last chunk and confirm that the final checksum and asset count remain correct. Run this test with a realistic asset and record the observed state, output URL, and failure reason.
Implementation check
- Resume from the server offset after reconnecting.
- Bind each session to an owner, size, and expiration.
- Check the completed length and checksum before publication.
Related guides
Primary reference: Official documentation.
Related field note
Continue with The maintenance burden behind resumable upload protocols.