104 Upload Resumption Supported

Interrupted file uploads traditionally restart from the first byte. The 104 Upload Resumption Supported informational response status code addresses this by telling the client, during an ongoing upload, that the transfer is resumable. The server sends this interim 1xx response before the final response, announcing the upload resource where an interrupted transfer continues from the last recorded offset.

Table of Contents

Usage
Example
See also

Usage

The server sends 104 Upload Resumption Supported as an interim response while an upload request is still in flight, for two purposes.

The first purpose is announcing the upload resource. When a client starts an upload with the Upload-Complete header field, the server creates an upload resource and advertises the address in the Location header of the 104 Upload Resumption Supported interim response, together with any size or expiry limits in Upload-Limit. If the connection drops before the final response arrives, the client resumes the transfer against that upload resource instead of starting over.

The second purpose is progress reporting. While the server processes the request content, it sends repeated 104 Upload Resumption Supported interim responses carrying the Upload-Offset header field with the number of bytes received so far. The client displays accurate progress and releases buffered data, knowing those bytes never need retransmitting.

Resuming after an interruption

Resumption is a three-step exchange against the upload resource announced in the interim response. The client first retrieves the current offset with a HEAD request. The server answers with a successful response such as 204, carrying the Upload-Offset header field. The client then appends the remaining bytes with a PATCH request using the application/partial-upload media type, setting Upload-Offset to match. During the append, the server again sends 104 Upload Resumption Supported interim responses to report progress. A client abandoning the transfer sends DELETE to the upload resource to cancel the upload and free the stored bytes.

Relationship with 100 Continue

A client sending the Expect header with 100-continue may treat an incoming 104 Upload Resumption Supported interim response as fulfilling the expectation and start transmitting the request content. The server still sends the separate 100 response, since both interim responses serve different purposes and clients without resumable upload support wait for 100 alone.

Draft interop version

While the specification is a draft, implementations exchange the Upload-Draft-Interop-Version header field to confirm they speak the same draft revision. Clients include the header in requests, and servers send 104 Upload Resumption Supported only when the value matches the revision they implement, echoing the header in the interim response. The current interop version is 9. This handshake keeps final RFC implementations separate from draft-era deployments.

Example

The client uploads a 50 MB video in a single request and signals with Upload-Complete ?1 that the whole representation is included. The Upload-Draft-Interop-Version header confirms the draft revision in use.

Request

POST /videos HTTP/1.1
Host: www.example.re
Content-Type: video/mp4
Content-Length: 52428800
Upload-Length: 52428800
Upload-Complete: ?1
Upload-Draft-Interop-Version: 9

<video bytes follow as the message body>

The server supports resumable uploads and immediately announces the upload resource. The Upload-Limit value tells the client the resource accepts uploads up to 1 GB.

Interim response

HTTP/1.1 104 Upload Resumption Supported
Location: https://www.example.re/uploads/f81d4fae
Upload-Limit: max-size=1073741824
Upload-Draft-Interop-Version: 9

Halfway through the transfer, the server reports progress. The offset of 26214400 confirms the first 25 MB arrived and never need retransmitting.

Interim response

HTTP/1.1 104 Upload Resumption Supported
Upload-Offset: 26214400
Upload-Draft-Interop-Version: 9

The upload completes, and the server sends the final response produced from processing the video.

Final response

HTTP/1.1 200 OK
Upload-Complete: ?1
Content-Type: application/json

{"videoId": "f81d4fae"}

Had the connection dropped after the progress report, the client would ask the upload resource for the current offset and append the remaining bytes from there.

Offset retrieval and append

HEAD /uploads/f81d4fae HTTP/1.1
Host: www.example.re
Upload-Draft-Interop-Version: 9

HTTP/1.1 204 No Content
Upload-Offset: 26214400
Upload-Length: 52428800
Upload-Complete: ?0
Upload-Limit: max-size=1073741824
Cache-Control: no-store

PATCH /uploads/f81d4fae HTTP/1.1
Host: www.example.re
Content-Type: application/partial-upload
Content-Length: 26214400
Upload-Offset: 26214400
Upload-Complete: ?1
Upload-Draft-Interop-Version: 9

<remaining video bytes follow as the message body>