Summary

  • draft-ietf-httpbis-resumable-upload-12 makes Upload-Offset an application-level acknowledgement of representation bytes processed by a temporary upload resource and a guarantee that the prefix need not be retransmitted.
  • That offset does not prove explicit completion, a matching digest, a clean content scan, current authority, target-resource acceptance, publication or downstream effect; each is a separate state transition with its own evidence.

The incident dashboard showed 8,000,000 of 8,000,000 bytes. The network had recovered, the temporary upload resource returned the same offset, and the client had released its local chunks. A green event called asset_created moved the item into the publishing queue.

No one had received the final response from the resource that was asked to create the asset. The upload was still explicitly incomplete. Its authorization grant had expired during the interruption, and the assembled representation had not passed the scanner that only ran at finalization.

The number was true. The conclusion was false.

Revision 12 of Resumable Uploads for HTTP, published on 6 July 2026, gives HTTP a careful way to recover from interrupted uploads. It is an active Internet-Draft of the HTTP Working Group, intended for the Standards Track and expiring on 7 January 2027. It is not yet an RFC, a deployment report, an interoperability result or evidence of adoption. Its strongest operational lesson is already visible: progress becomes trustworthy when its claim is kept narrow.

A temporary resource holds continuity, not the final meaning

The design inserts an upload resource between the client and the resource targeted by the original request. That temporary resource belongs to one representation. The client can ask it for progress, append more representation data or cancel the upload. The server persists its state and can retain it after completion long enough for a client that missed the last response to verify what happened.

This separation is not administrative clutter. It is the mechanism that lets an interrupted transfer resume without replaying the entire body. It is also a warning against collapsing two authorities. The upload resource accounts for transfer continuity. The original target applies the method and application semantics: create this object, replace that state, start that job, or reject the request.

A handle for the temporary resource can therefore exist while the intended object does not. A client may be allowed to append bytes while no longer being allowed to finalize them. The temporary state may survive a network break while a quota, approval or legal basis changes. Treating the upload URL as the identity of the final object erases the precise boundary that makes the protocol safe to reason about.

Offset means processed, not merely delivered

Upload-Offset counts bytes of representation data processed by the upload resource. The draft deliberately places this above transport acknowledgement. TCP, QUIC or another HTTP transport may have delivered and acknowledged bytes that the application has not yet incorporated into upload state. A client resumes from the server's application-level offset, not from a packet counter.

When the server returns an offset, it acknowledges that prefix and guarantees that the client will not need to retransmit it. That is strong evidence. It allows the client to free memory, discard a local chunk or advance a durable send cursor. It does not say where the bytes ultimately reside, how long every underlying component will retain them, whether they form a permitted representation or what the target will do with them.

The offset must not decrease because already processed representation data cannot be removed from the upload resource. If the server loses any part of the required state, the draft does not let it invent a lower number or guess a recovery point. It must deactivate the resource and reject further interaction. Monotonicity is valuable only when the system refuses to manufacture continuity after the evidence is gone.

Equal numbers are not a completion ceremony

Representation length and offset answer different questions. Length describes the size of the representation once known. Offset describes the processed prefix. The draft states the uncomfortable case plainly: offset can equal length while the upload remains incomplete.

That can happen because the client has not explicitly marked the operation complete. A streaming producer may have no more bytes at this moment but has not closed the representation. A deliberate multi-request strategy may have sent its current material while retaining the right to append. An empty final append can later declare completion after all data arrived in earlier requests.

Upload-Complete is therefore its own Boolean state. On creation or append, a true final response means the semantics of the original target apply; a false response remains within the resumable-upload protocol. Even this needs careful reading. A target can generate an early response, so Upload-Complete: ?1 can appear without the full representation having crossed the wire. Completion is a protocol decision, not a byte arithmetic shortcut.

An alert built from offset == length should say “known bytes processed.” It should not say “upload succeeded.” The final response, target semantics and application record must supply that later claim.

104 opens a recovery path; it does not close the operation

Status code 104, Upload Resumption Supported, is an interim response. During creation it can disclose the upload-resource URI and applicable limits. While the server processes a request, later 104 responses can report the current offset. This is a useful early receipt because a client that loses the connection after learning the URI can recover.

An interim response is not the target's final answer. A user interface that paints 104 green and announces success has confused the availability of a continuation mechanism with acceptance of the requested action. The distinction matters most in optimistic creation: the client may already be sending the whole representation, yet if interruption occurs before it receives the 104 and URI, it cannot resume that attempt.

Careful creation makes the opposite trade. It first creates an empty upload resource, obtains its URI and limits, then starts sending data. The additional round trip buys a durable recovery coordinate. Neither strategy changes the final authority of the target resource.

A 409 is a state reconciliation, not an invitation to guess

Every append includes the client's view of the offset. If it differs from the upload resource's current offset, the server returns 409 Conflict with its own offset and completeness state. This prevents two writers, retries or reordered knowledge from silently splicing bytes at the wrong point.

The safe response is to reconcile. Retrieve current state, compare the source representation, determine whether the disputed prefix is identical, and resume only under a defined retry policy. Blindly adding the rejected chunk again can duplicate content. Blindly trusting a locally cached offset can overwrite the meaning of the server receipt.

Parallel transfers for one upload resource are not supported. Servers serialize append and cancellation interactions. But serialization inside the server cannot give the client knowledge of a final response it never received. The client still needs an explicit state query and an idempotent business rule for the original operation.

Integrity and safety sit after assembly

Progress does not establish integrity. Content and representation digests have their own semantics. A system must specify which bytes the digest covers, when it is checked and what happens on mismatch. A progress counter cannot prove that a digest existed or matched.

The same is true for security scanning. A scanner that examines each PATCH request as if it were a complete object can miss a malicious pattern split across request boundaries. The draft warns that resumable uploads can defeat controls designed around one complete request. The assembled representation must be evaluated before it is made executable, public or available to a downstream parser.

The bytes and their metadata remain untrusted input. Filenames, content disposition, media type and storage hints do not acquire safety from a correct offset. The target must still validate or sanitize every field it uses.

Authorization can expire while the bytes wait

An upload resource can live much longer than one HTTP exchange. A permission checked at creation may no longer be valid when the last chunk arrives. The user may have left the organization, a quota may have filled, a case may have closed or a retention rule may have changed.

The draft calls out this time-of-check to time-of-use risk and recommends validating current privileges and quota before finalization. A hard-to-guess upload URI reduces accidental discovery, but it is not a durable grant. The server should authorize access to the upload resource, scope the handle, give it a lifetime and re-evaluate the requested action at the point of commit.

This produces an eight-rung evidence ladder: transport delivery; application-processed prefix; synchronized offset and length; explicit completion; integrity and content-policy acceptance; current authorization; target-resource commit; downstream business effect. Each rung may be true while the next remains false.

Sources and limits

The frozen packet covers revision 12 and its Datatracker history, the HTTP Working Group issue surface, HTTP semantics and caching, HTTP/1.1, HTTP/2, QUIC, Digest Fields, PATCH, Problem Details and Content-Disposition. These sources define protocol mechanics and adjacent controls. They do not show implementation prevalence, performance, interoperability, a real breach or the behavior of any named service.

Sources