Resumable upload

Plain HTTP POST, as RFC 9110 defines it, has no resume. The client either finishes the request or sends it again. Resumable behavior is an extra protocol on top.

The tus protocol is one explicit design. The client creates an upload, learns a URL, and PATCHes chunks. The server tells it the current offset. After a failure the client HEADs that URL, reads the offset, and sends the remainder. An optional checksum extension hashes each PATCH. A mismatch returns 460 and the server discards that chunk without moving the offset. Object-store multipart upload is a different resume: parts are numbered, a failed part is retried, and a complete call assembles them. Both avoid resending gigabytes. They are not the same API.

A field tech uploads a 4 GB site video on a truck LTE link. The session dies at 1.6 GB when the truck moves. A non-resumable form starts at byte 0 and spends another half hour repeating data that already arrived. A tus client reads offset 1,677,721,600 and continues. If the server expired the partial after 24 hours, the HEAD fails and the client must create a new upload. The first 1.6 GB is gone. Expiry of the partial is a server policy, not a promise of the word "resumable."

Resume is not the same as a retry of the whole file. Retry without an offset can create two objects if the first request actually finished and the response was lost. Idempotency keys or a create-then-patch flow prevent that. Checksum of the assembled file still matters. A resumed upload can be complete in length and wrong in bytes if a chunk was applied twice or skipped. Compare size and hash before you tell the recipient the file is ready.