Upload-Complete
The unofficial Upload-Complete header field marks whether a resumable upload request carries the final bytes of the representation or an intermediate chunk with more to follow.
Usage
The Upload-Complete header field appears on the request creating an upload resource, sent with POST, PUT, or any other method carrying content, and on every PATCH request appending to one. A true value states the request content ends the representation. A false value states more appends follow, so the server keeps the upload resource open after processing the content.
Presence of the header on the initial request is also the signal activating resumable handling: a server supporting the protocol advertises the upload resource in a Location header, on a 104 interim response or on the final response to the creation request. The upload counts as completed once a request with a true value has been fully processed. Clients avoid appending to a finished upload, and a server receiving a valid append against one is free to replay the final response instead of rejecting the request.
A client abandoning a transfer cancels the upload with a DELETE request against the upload resource instead of leaving the resource to expire.
The split into chunks serves clients on unreliable networks. Sending a large file as a series of smaller appends, each marked incomplete until the last, bounds the data lost to any single connection drop, at the cost of one round trip per chunk.
Responses carry the field with a different meaning: on creation, append, and offset-retrieval responses, Upload-Complete states whether the server has produced a final response from processing the representation. The value is true even before every byte arrives when the server generates an early response, so a true value signals processing finished rather than transmission finished.
Values
The value is a Structured Fields Item holding a
Boolean, serialized as ?1 for true and ?0 for
false.
Example
The examples leave out the Upload-Draft-Interop-Version
handshake, which 104 covers.
A client uploads a video in two parts. The creation request marks the upload incomplete, and the final append closes the transfer.
Request
POST /videos HTTP/1.1
Host: www.example.re
Upload-Complete: ?0
Content-Type: video/mp4
Content-Length: 5242880
[first 5242880 bytes]
Response
HTTP/1.1 104 Upload Resumption Supported
Location: https://www.example.re/uploads/b3k2pp5k7z
After processing the first chunk, the server answers the creation request with a final response naming the upload resource again.
Response
HTTP/1.1 201 Created
Location: https://www.example.re/uploads/b3k2pp5k7z
Upload-Complete: ?0
Request
PATCH /uploads/b3k2pp5k7z HTTP/1.1
Host: www.example.re
Upload-Offset: 5242880
Upload-Complete: ?1
Content-Type: application/partial-upload
Content-Length: 1310720
[final 1310720 bytes]
See also
- Internet-Draft: Resumable Uploads for HTTP
- Upload-Offset
- Upload-Length
- Upload-Limit
- 104
- POST
- PATCH
- HTTP headers