HTTP 104 Upload Resumption Supported

Quick reference

The resumable upload problem

Large file uploads over standard HTTP face a reliability problem: if the network connection is interrupted mid-upload (mobile network handoff, browser tab closed, server timeout), the entire upload is lost and must restart from byte zero. For a 2GB file upload where 1.9GB transferred successfully, a single network hiccup means starting over.

Resumable upload protocols address this by:

First, establishing an upload session with a unique upload ID before sending data. Second, sending the file in chunks with offset tracking — each chunk tagged with its byte offset in the complete file. Third, allowing the client to query the server for the current upload offset after an interruption. Fourth, resuming from that offset, skipping the bytes the server already received.

The proposed 104 code fits into this flow as an early signal from the server: “I support resumable uploads. Here is your upload session ID and the current upload offset.” The client receives 104 at the start of the upload and uses the session ID for offset queries after any interruption.

Resumable upload protocols in production

Several production resumable upload protocols exist that do not use 104, since 104 has not been standardized:

tus protocol (tus.io): The most widely adopted open specification for resumable uploads. Uses POST to create an upload resource, PATCH to send chunks with Upload-Offset headers, and HEAD to query the current offset. Server capabilities are declared via Tus-Resumable and Tus-Extension response headers. Does not use 104. Implemented in Vimeo, Microsoft OneDrive, and many storage platforms.

POST /files HTTP/1.1
Content-Length: 0
Upload-Length: 104857600
Tus-Resumable: 1.0.0

HTTP/1.1 201 Created
Location: /files/24e533e02ec3bc
Tus-Resumable: 1.0.0

PATCH /files/24e533e02ec3bc HTTP/1.1
Upload-Offset: 0
Content-Length: 10485760
Content-Type: application/offset+octet-stream

[first 10MB of file data]

HTTP/1.1 204 No Content
Upload-Offset: 10485760

Google Resumable Upload API: Uses a two-step process: an initiating POST that returns a resumable session URI in the Location header, followed by PUT requests to the session URI. Session state is tracked server-side. If interrupted, the client sends an empty PUT with Content-Range: bytes */{total} to query the current offset.

AWS S3 Multipart Upload: Splits the file into parts (minimum 5MB each), uploads each part independently, then combines with a CompleteMultipartUpload request. Parts can be retried individually without restarting the entire upload.

The IETF draft context

The IETF HTTP working group has discussed standardizing resumable uploads at the HTTP protocol level. Draft proposals (such as draft-ietf-httpbis-resumable-upload) have proposed using 104 as an interim response during an upload to convey the session ID and resumption information before the upload body is fully received. Under this proposal:

POST /upload HTTP/1.1
Content-Type: video/mp4
Content-Length: 2147483648
Upload-Complete: ?0

HTTP/1.1 104 Upload Resumption Supported
Location: /upload/sessions/abc123
Upload-Offset: 0

[client continues sending upload body...]

HTTP/1.1 201 Created
Location: /videos/xyz789

The 104 would allow the server to return a session URI while the upload is still in progress, giving the client everything it needs to resume without completing the upload first. As of this writing, this draft had not been finalized.

What to use today for resumable uploads

For production resumable uploads, use an established protocol rather than waiting for 104 to be standardized:

For direct-to-storage uploads: AWS S3 Multipart Upload, Google Cloud Storage Resumable Uploads, or Azure Block Blob uploads. These are battle-tested, handle TB-scale files, and are supported by every major storage SDK.

For application-level resumable uploads: The tus protocol has open-source client and server libraries for JavaScript (browser and Node.js), Python, Go, Ruby, Java, iOS, and Android. Tusd is the official tus server implementation.

For browser-based uploads: Use the tus-js-client library for browser uploads with automatic retry and resumption. For simpler use cases, chunked XHR or fetch with manual offset tracking works for smaller files where the overhead of a full resumable upload protocol is not justified.

Frequently asked questions

What does HTTP 104 mean?

104 is an unassigned informational status code that has been proposed for use in resumable HTTP upload protocols to signal that the server supports upload resumption. It has not been standardized in any published RFC and is not in mainstream use. If encountered in the wild, check the server documentation for its specific meaning.

Is HTTP 104 the same as the tus protocol?

No. The tus protocol uses 201, 204, and custom headers rather than 104. They address the same problem (resumable uploads) but are different specifications. The proposed 104 code would be part of a future IETF standard for HTTP-native resumable uploads, separate from tus.

How does a client handle a 104 response it does not understand?

Per RFC 9110, clients must be able to handle 1xx informational responses by ignoring them and waiting for the final response. An HTTP client that receives an unrecognized 1xx code should discard it without closing the connection. The upload or request continues normally.

What is the difference between 100 Continue and 104 Upload Resumption Supported?

100 Continue is a standardized response to Expect: 100-continue that tells the client its headers are acceptable and it should send the body. 104 (proposed) would be a proactive signal from the server at the start of an upload that the server supports resumption and providing a session ID. They serve different purposes in different upload scenarios.

Related guides

HTTP 100 Continue · HTTP 201 Created · HTTP 204 No Content

Standards reference

Definitions from the IANA HTTP Status Code Registry. 104 is not assigned; draft context from IETF httpbis working group documents. · HTTP 104 quick reference →