HTTP Working Group M. Kleidl, Ed. Internet-Draft Transloadit Intended status: Standards Track G. Zhang, Ed. Expires: January 7, 2027 Apple Inc. L. Pardue, Ed. Cloudflare July 6, 2026 Resumable Uploads for HTTP draft-ietf-httpbis-resumable-upload-12 Abstract HTTP data transfers can encounter interruption due to reasons such as canceled requests or dropped connections. If the intended recipient can indicate how much of the data was processed prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Working Group information can be found at . Source for this draft and an issue tracker can be found at . Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Kleidl, et al. Expires January 7, 2027 [Page 1] Internet-Draft Resumable Uploads July 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 7, 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Example 1: Complete upload of representation data with known size . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Example 2: Upload as a series of parts . . . . . . . . . 8 4. Upload Resource . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. State . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Offset . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Completeness . . . . . . . . . . . . . . . . . . . . 11 4.1.3. Length . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.4. Limits . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Upload Creation . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 16 4.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 17 4.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 19 4.3. Offset Retrieval . . . . . . . . . . . . . . . . . . . . 21 4.3.1. Client Behavior . . . . . . . . . . . . . . . . . . . 21 4.3.2. Server Behavior . . . . . . . . . . . . . . . . . . . 21 4.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 22 4.4. Upload Append . . . . . . . . . . . . . . . . . . . . . . 22 4.4.1. Client Behavior . . . . . . . . . . . . . . . . . . . 23 4.4.2. Server Behavior . . . . . . . . . . . . . . . . . . . 23 4.4.3. Examples . . . . . . . . . . . . . . . . . . . . . . 25 Kleidl, et al. Expires January 7, 2027 [Page 2] Internet-Draft Resumable Uploads July 2026 4.5. Upload Cancellation . . . . . . . . . . . . . . . . . . . 26 4.5.1. Client Behavior . . . . . . . . . . . . . . . . . . . 26 4.5.2. Server Behavior . . . . . . . . . . . . . . . . . . . 26 4.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 26 4.6. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 27 4.7. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Status Code 104 (Upload Resumption Supported) . . . . . . . . 28 6. Media Type application/partial-upload . . . . . . . . . . . . 29 7. Problem Types . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Mismatching Offset . . . . . . . . . . . . . . . . . . . 29 7.2. Inconsistent Length . . . . . . . . . . . . . . . . . . . 30 8. Content Codings . . . . . . . . . . . . . . . . . . . . . . . 30 9. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 31 10. Upload Strategies . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Optimistic Upload Creation . . . . . . . . . . . . . . . 31 10.1.1. Upgrading To Resumable Uploads . . . . . . . . . . . 32 10.2. Careful Upload Creation . . . . . . . . . . . . . . . . 33 11. Incremental Transfer, Processing and Forwarding . . . . . . . 33 12. Request Cancellation . . . . . . . . . . . . . . . . . . . . 33 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 14.1. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . 35 14.2. HTTP Status Code . . . . . . . . . . . . . . . . . . . . 36 14.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 36 14.4. HTTP Problem Types . . . . . . . . . . . . . . . . . . . 37 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.1. Normative References . . . . . . . . . . . . . . . . . . 38 15.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 39 A.1. Since draft-ietf-httpbis-resumable-upload-11 . . . . . . 39 A.2. Since draft-ietf-httpbis-resumable-upload-10 . . . . . . 40 A.3. Since draft-ietf-httpbis-resumable-upload-09 . . . . . . 40 A.4. Since draft-ietf-httpbis-resumable-upload-08 . . . . . . 41 A.5. Since draft-ietf-httpbis-resumable-upload-07 . . . . . . 41 A.6. Since draft-ietf-httpbis-resumable-upload-06 . . . . . . 41 A.7. Since draft-ietf-httpbis-resumable-upload-05 . . . . . . 41 A.8. Since draft-ietf-httpbis-resumable-upload-04 . . . . . . 42 A.9. Since draft-ietf-httpbis-resumable-upload-03 . . . . . . 42 A.10. Since draft-ietf-httpbis-resumable-upload-02 . . . . . . 42 A.11. Since draft-ietf-httpbis-resumable-upload-01 . . . . . . 43 A.12. Since draft-ietf-httpbis-resumable-upload-00 . . . . . . 43 A.13. Since draft-tus-httpbis-resumable-uploads-protocol-02 . . 43 A.14. Since draft-tus-httpbis-resumable-uploads-protocol-01 . . 43 A.15. Since draft-tus-httpbis-resumable-uploads-protocol-00 . . 43 Appendix B. Draft Version Identification . . . . . . . . . . . . 43 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Kleidl, et al. Expires January 7, 2027 [Page 3] Internet-Draft Resumable Uploads July 2026 1. Introduction HTTP data transfers can encounter interruption due to reasons such as canceled requests or dropped connections. If the intended recipient can indicate how much of the data was processed prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests (see Section 14 of [HTTP]) support this concept of resumable data transfers for downloads from server to client. While partial PUT is one method for uploading a partial representation (via Content-Range in the request), there are caveats that affect its deployability; see Section 14.5 of [HTTP]. Canceled upload request can be triggered for various reasons, including but not limited to: explicit client cancellation: e.g., terminating a user-agent process implicit client cancellation: e.g., terminating a tab, garbage collecting a process or internal error explicit server cancellation: e.g., scheduled maintenance implicit server cancellation: e.g., DoS mitigation or internal error Connections can be dropped due to a variety of network or transport layer reasons triggered by endpoints or on-path elements. This specification defines a new mechanism for resumable uploads from client to server that can seamlessly fall back to conventional uploads. When an upload is interrupted, clients can send subsequent requests to query the server state and use this information to send the remaining representation data. Alternatively, they can cancel the upload entirely. Unlike ranged downloads, this protocol does not support transferring an upload as multiple requests in parallel. Utilizing resumable uploads, applications can recover from unintended interruptions, but also interrupt an upload on purpose to later resume it, for example, when a user wants to pause an upload, the device's network connectivity changes, or bandwidth should be saved for higher priority tasks. The document introduces the concept of an upload resource to facilitate resumable uploads (Section 4) and defines new header fields to communicate the state of the upload (Section 4.1), the status code "104 (Upload Resumption Supported)" to indicate the resource's support for resumable uploads (Section 5), and the Kleidl, et al. Expires January 7, 2027 [Page 4] Internet-Draft Resumable Uploads July 2026 "application/partial-upload" media type to label partial representation data when resuming an upload (Section 6). 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Some examples in this document contain long lines that may be folded, as described in [RFC8792]. The terms Structured Header, Item, Dictionary, String, Integer, and Boolean are imported from [STRUCTURED-FIELDS]. The terms "representation", "representation data", "representation metadata", "content", "client" and "server" are from Section 3 of [HTTP]. The term "URI" is used as defined in Section 4 of [HTTP]. The term "patch document" is taken from [PATCH]. An _upload resource_ is a temporary resource on the server that facilitates the resumable upload of one representation (Section 4). 3. Overview Resumable uploads are supported in HTTP through use of a temporary resource, an _upload resource_ (Section 4), that is separate from the resource being uploaded to and specific to that upload. By interacting with the upload resource, a client can retrieve the current offset of the upload (Section 4.3), append to the upload (Section 4.4), and cancel the upload (Section 4.5). The remainder of this section uses examples to illustrate different interactions with the upload resource. HTTP message exchanges, and thereby resumable uploads, use representation data (see Section 8.1 of [HTTP]). This means that resumable uploads can be used with many forms of content, such as static files, in-memory buffers, data from streaming sources, or on-demand generated data. Examples are purely illustrative and non-normative. Implementations of this protocol are expected to follow normative requirements defined in other sections, together with applying security considerations presented in Section 13. Kleidl, et al. Expires January 7, 2027 [Page 5] Internet-Draft Resumable Uploads July 2026 3.1. Example 1: Complete upload of representation data with known size In this example, the client first attempts to upload representation data with a known size in a single HTTP request to the resource at "/project/123/files". An interruption occurs and the client then attempts to resume the upload using subsequent HTTP requests to the upload resource at "/uploads/abc". 1) The client notifies the server that it wants to begin an upload (Section 4.2). The server reserves the required resources to accept the upload from the client and then sends an interim response to the client, signaling support for resumable uploads and the upload resource's URI via the Location header field (Section 10.2.2 of [HTTP]). The client can start sending the representation data in the request content immediately after the request header section. Alternatively, it could also await the acknowledgment in the form of the interim response. Client Server | | | POST /project/123/files | | Upload-Complete: ?1 | | | | [representation] | |------------------------------------------->| | | | | Reserve resources | | for upload | |-----------------. | | | | |<----------------' | | | 104 Upload Resumption Supported | | Location: /uploads/abc | |<-------------------------------------------| | | X--------------Flow Interrupted--------------X Figure 1: Upload Creation 2) If the connection to the server is interrupted, the client might want to resume the upload. However, before this is possible the client needs to know the amount of representation data that the server processed before the interruption. It does so by retrieving the offset (Section 4.3) from the upload resource. Kleidl, et al. Expires January 7, 2027 [Page 6] Internet-Draft Resumable Uploads July 2026 Client Server | | | HEAD /uploads/abc | |------------------------------------------------>| | | | 204 No Content | | Upload-Offset: X | |<------------------------------------------------| | | Figure 2: Offset Retrieval 3) The client can resume the upload by sending the remaining representation data to the upload resource (Section 4.4), appending to the already stored representation data in the upload using the "application/partial-upload" media type. The "Upload-Offset" value is included to ensure that the client and server agree on the offset that the upload resumes from. Once the remaining representation data is transferred, the server processes the entire representation and responds with whatever the initial request to "/project/123/files" would have produced if it had not been interrupted, e.g., a "200 (OK)" response. Client Server | | | PATCH /uploads/abc | | Upload-Complete: ?1 | | Upload-Offset: X | | Content-Type: application/partial-upload | | | | [representation from offset X] | |------------------------------------------------>| | | | 200 OK | |<------------------------------------------------| | | Figure 3: Upload Append 4) If the client is not interested in completing the upload, it can instruct the server to delete the upload resource and all associated representation data (Section 4.5). Kleidl, et al. Expires January 7, 2027 [Page 7] Internet-Draft Resumable Uploads July 2026 Client Server | | | DELETE /uploads/abc | |------------------------------------------------>| | | | 204 No Content | |<------------------------------------------------| | | Figure 4: Upload Cancellation 3.2. Example 2: Upload as a series of parts In some cases, clients might prefer to upload a representation as a series of parts sent serially across multiple HTTP messages. One use case is to overcome server limits on HTTP message content size. Another use case is where the client does not know the final size of the representation data, such as when the data originates from a streaming source. This example shows how the client, communicating with a resource known to support resumable upload, can upload parts of a representation incrementally. 1) The client is aware that the targeted resource supports resumable uploads and therefore starts the upload with the "Upload-Complete" field value set to false and the first part of the representation. Client Server | | | POST /project/123/files | | Upload-Complete: ?0 | | | | [partial representation] | |------------------------------------------------>| | | | 201 Created | | Location: /uploads/abc | |<------------------------------------------------| | | Figure 5: Upload creation with partial representation data 2) Next, intermediate parts are appended (Section 4.4) with the "Upload-Complete" field value set to false, indicating that they are not the last part of the representation data. The offset value in the "Upload-Offset" header field is taken from the previous response when creating the upload or appending to it. Kleidl, et al. Expires January 7, 2027 [Page 8] Internet-Draft Resumable Uploads July 2026 Client Server | | | PATCH /uploads/abc | | Upload-Complete: ?0 | | Upload-Offset: X | | Content-Type: application/partial-upload | | | | [partial representation from offset X] | |------------------------------------------------>| | | | 204 No Content | |<------------------------------------------------| | | Figure 6: Appending partial representation data to upload 3) If the connection was interrupted, the client might want to resume the upload, similar to the previous example (Section 3.1). The client retrieves the offset (Section 4.3) to learn the amount of representation data processed by the server and then continues appending the remaining parts to the upload as in the previous step. Client Server | | | HEAD /uploads/abc | |------------------------------------------------>| | | | 204 No Content | | Upload-Offset: Y | |<------------------------------------------------| | | | PATCH /uploads/abc | | Upload-Complete: ?0 | | Upload-Offset: Y | | Content-Type: application/partial-upload | | | | [partial representation from offset Y] | |------------------------------------------------>| | | | 204 No Content | |<------------------------------------------------| | | Figure 7: Resuming an interrupted upload 4) The request to append the last part of the representation data has an "Upload-Complete" field value set to true to indicate the complete transfer. Once the remaining representation data is transferred, the Kleidl, et al. Expires January 7, 2027 [Page 9] Internet-Draft Resumable Uploads July 2026 server processes the entire representation and responds with whatever the initial request to "/project/123/files" would have produced if its representation had been fully transferred and processed, e.g., a "200 (OK)" response. Client Server | | | PATCH /uploads/abc | | Upload-Complete: ?1 | | Upload-Offset: Z | | Content-Type: application/partial-upload | | | | [remaining representation from offset Z] | |------------------------------------------------>| | | | 200 OK | |<------------------------------------------------| | | Figure 8: Appending remaining representation data 4. Upload Resource A resumable upload is enabled through interaction with an upload resource. When a resumable upload begins, the server is asked to create an upload resource through a request to another resource (Section 4.2). Using this upload resource, the client can query the upload progress (Section 4.3), append representation data (Section 4.4), or cancel the upload (Section 4.5). The server is responsible for persisting the state of the upload resource (Section 4.1) and updating it as the upload progresses. An upload resource is specific to the upload of one representation. For uploading multiple representations, multiple upload resources have to be used. The server can clean up an upload resource and make it inaccessible immediately after the upload is complete. However, keeping the upload resource available for a period of time after completion allows the client to verify the state of the upload if it did not receive the last response acknowledging the completion. Implementations are responsible for deciding if they retain the resource and for what duration; they will need to consider the resource costs required to do so. An upload resource SHOULD be unique. Reuse of a URI for a different upload resource SHOULD be avoided in order to reduce the chance of Kleidl, et al. Expires January 7, 2027 [Page 10] Internet-Draft Resumable Uploads July 2026 misdirected or corrupted upload resources, as well as the potential security issues described in Section 13. 4.1. State The state of an upload consists of the following properties that are tracked by the server. 4.1.1. Offset The offset is the number of bytes from the representation data that have been processed, either during the creation of the upload resource (Section 4.2) or by appending to it (Section 4.4). The offset can be retrieved from the upload resource (Section 4.3) and is required when appending representation data (Section 4.4) to synchronize the client and resource regarding the amount of transferred representation data. The offset reflects application-level processing for the upload. Data may have been delivered and acknowledged at the transport layer without yet being reflected in the offset. Representation data processed by the upload resource cannot be removed again and, therefore, the offset MUST NOT decrease. If the server loses any part of the state, it MUST deactivate the upload resource and reject further interaction with it. The "Upload-Offset" request and response header field conveys the offset. "Upload-Offset" is an Item Structured Header Field ([STRUCTURED-FIELDS]). Its value is a non-negative Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) and indicates the current offset as viewed by the message sender. Other values MUST cause the entire header field to be ignored. The "Upload-Offset" header field in responses serves as an acknowledgment of the processed representation data and as a guarantee that no retransmission of it will be necessary. Clients can use this guarantee to free resources associated to transferred representation data. 4.1.2. Completeness An upload is incomplete until it is explicitly marked as completed by the client or the server. After this point, no more representation data can be appended. The "Upload-Complete" request and response header field conveys the completeness state. "Upload-Complete" is an Item Structured Header Kleidl, et al. Expires January 7, 2027 [Page 11] Internet-Draft Resumable Uploads July 2026 Field ([STRUCTURED-FIELDS]). Its value is a Boolean (Section 3.3.6 of [STRUCTURED-FIELDS]) and indicates whether the upload is complete or not. Other values MUST cause the entire header field to be ignored. An upload is marked as completed either when a request for creating the upload resource (Section 4.2) or appending to it (Section 4.4) includes the "Upload-Complete" header field with a true value and the request content was fully processed, or when a response includes the "Upload-Complete" header field with a true value. When used in an upload creation response (Section 4.2) or an upload append response (Section 4.4), "Upload-Complete" signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the "Upload- Complete" field value set to true. Note that "Upload-Complete" can be true even when the full representation data was not transmitted in the case that the server decides to generate an early response when processing the targeted resource. Also note that "Upload-Complete" can be false in response to an invalid operation performed on a completed upload. 4.1.3. Length The length of the representation data might not be known when starting the transfer, for example, because the representation is taken from a streaming source. The representation's length will, however, be known at the latest when the client completes the upload (Section 4.1.2). Despite this, a client SHOULD communicate the representation's length to the server as soon as it becomes known to aid with resource management and facilitate early validation. There are two different ways for the client to indicate and for the server to discover the representation's length from requests for creating the upload resource (Section 4.2) or appending to it (Section 4.4): 1. If the request includes the "Upload-Complete" field value set to true, the request content is the remaining representation data. The representation's length is then the sum of the current offset (Section 4.1.1) and the request content's length, which might be announced in the "Content-Length" header field. 2. The request can include the "Upload-Length" header field defined below. Kleidl, et al. Expires January 7, 2027 [Page 12] Internet-Draft Resumable Uploads July 2026 The "Upload-Length" request and response header field is an Item Structured Header Field ([STRUCTURED-FIELDS]). Its value is a non- negative Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) and indicates the representation's length as a number of bytes. Other values MUST cause the entire header field to be ignored. If indicators (1) and (2) are both present in the same request, their indicated lengths MUST match. The representation's length, if known, MUST stay consistent across subsequent requests. A server can use the problem type [PROBLEM] of "https://iana.org/assignments/http- problem-types#inconsistent-upload-length" (Section 7.2) in responses to indicate inconsistent length indicators. The "Upload-Length" field can be used in response to an offset retrieval; see Section 4.3.2. Note that the length and offset values do not determine whether an upload is complete. Instead, the client uses the "Upload-Complete" (Section 4.1.2) header field to indicate that a request completes the upload. The offset could match the length, but the upload can still be incomplete. 4.1.4. Limits A server MAY enforce one or multiple limits, which are communicated to the client via the "Upload-Limit" response header field. "Upload- Limit" is a Dictionary Structured Header Field ([STRUCTURED-FIELDS]). Its value is a Dictionary (Section 3.2 of [STRUCTURED-FIELDS]). Other values MUST cause the entire header field to be ignored. The following key-value pairs are defined: max-size: Specifies a maximum size for the representation data, counted in bytes. The server might not create an upload resource if the representation's length (Section 4.1.3) deduced from the upload creation request is larger than the maximum size. The server might also deactivate the upload resource if the offset (Section 4.1.1) exceeds the maximum size. The value is an Integer. min-size: Specifies a minimum size for the representation data, counted in bytes, for the server to offer resumable uploads. The server might not create an upload resource if the representation's length (Section 4.1.3) deduced from the upload creation request is smaller than the minimum size or no length can be deduced at all. Resumable uploads impose additional overhead on the server, which might not be acceptable for small representations. Requests with representation data below this value might still be accepted by Kleidl, et al. Expires January 7, 2027 [Page 13] Internet-Draft Resumable Uploads July 2026 the server, although without the ability to resume them. The value is an Integer. max-append-size: Specifies a maximum size counted in bytes for the request content in a single upload append (Section 4.4) or upload creation (Section 4.2) request. The server might reject requests exceeding this limit. A client that is aware of this limit MUST NOT send larger upload append or upload creation requests. The value is an Integer. min-append-size: Specifies a minimum size counted in bytes for the request content in a single upload append (Section 4.4) or upload creation (Section 4.2) request. The server might reject requests below this limit. A client that is aware of this limit MUST NOT send smaller upload append or upload creation requests. The value is an Integer. This limit does not apply to upload creation requests with no content, or to requests completing the upload by including the "Upload-Complete: ?1" header field. max-age: Specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response. After the resource's lifetime is reached, the server might make the upload resource inaccessible and a client SHOULD NOT attempt to access the upload resource as these requests will likely fail. The value is an Integer. Clients usually discover limits through the "Upload-Limit" header field when the upload resource is created (Section 4.2). Throughout the lifetime of the upload resource, these limits SHOULD NOT change in a way that causes failures for clients adhering to the initially discovered limits. If the client discovers that it cannot continue the upload while adhering to the limits, it SHOULD stop the current request immediately (Section 12) and cancel the upload (Section 4.5). The following recommendations for limit changes can minimize the risk of causing upload failures: o "max-size" and "max-append-size" SHOULD NOT decrease. o "min-size" and "min-append-size" SHOULD NOT increase. o Between subsequent responses, the end of the upload resource's lifetime as implied by "max-age" SHOULD NOT decrease. Receivers of "Upload-Limit" parse the Dictionary as described in Section 4.2 of [STRUCTURED-FIELDS]. Where the Dictionary is successfully parsed, this document places two additional requirements on Dictionary members. First, a member with an unknown key MUST be Kleidl, et al. Expires January 7, 2027 [Page 14] Internet-Draft Resumable Uploads July 2026 ignored. Second, a member with a known key but a value of unexpected type MUST cause the entire "Upload-Limit" header field to be ignored, or alternatively the complete HTTP message MUST be treated as malformed. When responding to an "OPTIONS" request without the "Upload-Complete" header field, if the resource that is the target of the request supports the creation of a resumable upload resource (Section 4.2), the server MUST include the "Upload-Limit" header field with the corresponding limits in the response. If a server is configured such that all of its resources support the creation of upload resources with identical limits, it SHOULD include the "Upload-Limit" header field in response to an "OPTIONS" request for the target "*" (if this target is supported). If the server does not apply any limits, it MUST use "min-size=0" instead of an empty header value. A client can use an "OPTIONS" request without the "Upload-Complete" header field to discover whether the resource supports resumable uploads and to learn potential limits before creating an upload resource. To reduce the likelihood of failing requests, the limits announced in an "OPTIONS" response SHOULD NOT be less restrictive than the limits applied to an upload once the upload resource has been created, unless the request to create an upload resource included additional information that warrants different limits. For example, a server might announce a general maximum size limit of 1 GB, but reduce it to 100 MB when the media type indicates an image. When a request is rejected because limits were violated, the response SHOULD include the "Upload-Limit" header field carrying all limits of the corresponding upload if possible. This might not be possible if intermediaries enforce limits. Servers, including intermediaries, can (and often do) apply restrictions on the size of individual request message content. There is no standard mechanism to communicate such existing size restriction. A server that implements one can respond with a "413 (Content Too Large)" status code; see Section 15.5.14 of [HTTP]. Appending to an upload resource, as a series of appends, can be used to upload data up to the "max-size" limit without encountering per- message limits. Servers might apply restrictions that are smaller than the append limits, which would also result in a failed request. When a client receives a response with a "413 (Content Too Large)" status code during upload creation (Section 4.2) or append (Section 4.4), it SHOULD retry the request with a smaller size residing between "min-append-size" and "max-append-size". If these limits are unknown at the time of receiving such a response, the client can attempt to discover them through an "OPTIONS" request. Kleidl, et al. Expires January 7, 2027 [Page 15] Internet-Draft Resumable Uploads July 2026 Retrying with the same request content size will likely yield the same error response. Cases where the request content size matches the "min-append-size" limit yet fails with a "413 (Content Too Large)" response might indicate a deployment mismatch that cannot be recovered from. 4.2. Upload Creation 4.2.1. Client Behavior A client can start a resumable upload from any request that can carry content by including the "Upload-Complete" header field (Section 4.1.2). As a consequence, all request methods that allow content are possible, such as "POST", "PUT", and "PATCH". The request can benefit from incremental delivery; see Section 11. The "Upload-Complete" header field is set to true if the request content includes the entire representation data that the client intends to upload. This is also a requirement for transparently upgrading to resumable uploads from conventional uploads (Section 10.1.1). If the client knows the representation's length, it SHOULD indicate the length in the request to help the server allocate necessary resources for the upload and provide early feedback if the representation violates a limit (Section 4.1.4), as described in Section 4.1.3. Clients are not required to discover limits (Section 4.1.4) before starting the upload and might therefore be initially unaware of limits enforced by the server. However, the client SHOULD respect any limits (Section 4.1.4) announced during the upload process in the "Upload-Limit" header field in interim or final responses. In particular, if the allowed maximum size is less than the amount of representation data the client intends to upload, the client SHOULD stop the current request immediately (Section 12) and cancel the upload (Section 4.5). If the client knows that the representation data is smaller than "min-size", it cannot expect resumability to be offered. The client might still attempt to transfer the representation in a single request, either in a request with the "Upload-Complete" header field set to true (see Section 10.1.1) or via a conventional upload. The request content can be empty. If the "Upload-Complete" header field is then set to true, the client intends to upload an empty representation. An "Upload-Complete" header field set to false is also valid. This can be used to retrieve the upload resource's URI before transferring any representation data. Since interim responses Kleidl, et al. Expires January 7, 2027 [Page 16] Internet-Draft Resumable Uploads July 2026 are optional, this technique provides another mechanism to learn the URI, at the cost of an additional round-trip before data upload can commence. Representation metadata included in the initial request (see Section 8.2 of [HTTP]) can affect how servers act on the uploaded representation data. The "Content-Type" header field (Section 8.3 of [HTTP]) indicates the media type of the representation. The "Content-Encoding" header field (Section 8.4 of [HTTP]) names the content codings applied to the representation. The "Content- Disposition" header field ([CONTENT-DISPOSITION]) can be used to transmit a filename. For this purpose, the "inline" disposition type is RECOMMENDED. If the client received a final response with the "Upload-Complete: ?1" header field, the upload is complete and the corresponding response comes from the resource processing the representation according to the initial request (Section 4.1.2). Note that this does not necessarily indicate success. "4xx (Client Error)" or "5xx (Server Error)" status codes indicate in this case an error occurred while processing the representation, and therefore, resuming the upload would not resolve this error. If the client receives a 2xx successful final response with the "Upload-Complete" header field set to false or missing, the "Location" response header field points the client to the created upload resource. The client can continue appending representation data to it (Section 4.4). If the client receives a 4xx client error or 5xx server error final response with the "Upload-Complete" header field set to false or missing, or if it did not receive a final response, it can apply the heuristics described in Section 4.7 to retry or resume the upload. 4.2.2. Server Behavior Upon receiving a request with the "Upload-Complete" header field, the server can choose to offer resumption support for this request by creating an upload resource. If so, the server SHOULD announce the upload resource by sending an interim response with the "104 (Upload Resumption Supported)" status code unless the server is not capable of sending interim responses. The interim response allows the client to resume the upload even if the message exchange gets later interrupted. When sent, it MUST include "Location" header field pointing to the upload resource and MUST include the "Upload-Limit" header field with the corresponding limits (Section 4.1.4) if existing. Kleidl, et al. Expires January 7, 2027 [Page 17] Internet-Draft Resumable Uploads July 2026 The resource targeted by this initial request is responsible for processing the representation data transferred in the resumable upload according to the method and header fields in the initial request. The upload resource, on the other hand, enables resuming the transfer. If the "Upload-Complete" request header field is set to true, the client intends to transfer the entire representation data in one request. If the request content was fully processed, no resumable upload is needed and the server proceeds to process the request and generate a response. If the "Upload-Complete" request header field is set to false, the client intends to transfer the representation over multiple requests. If the request content was fully processed, the server MUST include the "Location" response header field pointing to the upload resource and MUST include the "Upload-Limit" header field with the corresponding limits if existing. Servers are RECOMMENDED to use the "201 (Created)" status code. The server MUST record the representation's length according to Section 4.1.3 if the "Upload-Length" or "Upload-Complete: ?1" header fields are included in the request. While the request content is being processed, the server MAY send multiple interim responses with a "104 (Upload Resumption Supported)" status code and the "Upload-Offset" header field set to the current offset to inform the client about the upload progress. Where a response requires a "Location" header field to be included, all interim and final response messages for the same request MUST contain an identical "Location" value. However, final responses including the "Upload-Complete: ?1" header field are exempt from this requirement because they are the result of processing the transferred representation and the "Location" value does not necessarily represent the upload location. Where the "Location" value is expected to be identical across multiple messages, clients SHOULD verify this. If verification fails, clients SHOULD abort the current request and cancel the upload (Section 4.5). The server SHOULD include the "Upload-Complete" (Section 4.1.2) header field in the response to indicate whether it is the result of processing the uploaded representation. The server SHOULD NOT generate a response with the "301 (Moved Permanently)", "302 (Found)", or "303 (See Other)" status codes and the "Upload-Complete: ?0" header field because clients might follow the redirect without preserving the original method. Kleidl, et al. Expires January 7, 2027 [Page 18] Internet-Draft Resumable Uploads July 2026 The server might not process the entire request content when the upload is interrupted, for example because of dropped connection or canceled request. In this case, the server SHOULD append as much of the request content as possible to the upload resource, allowing the client to resume the upload from where it was interrupted. In addition, the upload resource MUST NOT be considered complete then. 4.2.3. Examples A) The following example shows an upload creation, where the entire 123456789 bytes are transferred in the initial request. The server sends multiple interim responses and one final response from processing the uploaded representation. POST /project/123/files HTTP/1.1 Host: example.com Content-Disposition: inline; filename="file name.jpg"; filename*=UTF-8''file%20name.jpg Content-Length: 123456789 Upload-Length: 123456789 Upload-Complete: ?1 [content (123456789 bytes)] HTTP/1.1 104 Upload Resumption Supported Location: https://example.com/upload/b530ce8ff Upload-Limit: max-size=1234567890 HTTP/1.1 104 Upload Resumption Supported Upload-Offset: 23456789 HTTP/1.1 200 OK Location: https://example.com/upload/b530ce8ff Upload-Complete: ?1 Upload-Limit: max-size=1234567890 Content-Type: application/json {"attachmentId": "b530ce8ff"} B) The following example shows an upload creation, where only the first 23456789 bytes of a 123456789 bytes upload are transferred. The server acknowledges the processed representation data and that the upload is not complete yet. The client can continue appending data. Kleidl, et al. Expires January 7, 2027 [Page 19] Internet-Draft Resumable Uploads July 2026 POST /upload HTTP/1.1 Host: example.com Upload-Complete: ?0 Content-Length: 23456789 Upload-Length: 123456789 [partial content (23456789 bytes)] HTTP/1.1 104 Upload Resumption Supported Location: https://example.com/upload/3fd4994ad HTTP/1.1 201 Created Location: https://example.com/upload/3fd4994ad Upload-Complete: ?0 Upload-Limit: max-size=1234567890 C) The following example shows an upload creation, where the server responds with a 5xx status code. Thanks to the interim response containing the upload resource URI, the client can resume the upload. POST /upload HTTP/1.1 Host: example.com Upload-Complete: ?1 Content-Length: 123456789 Upload-Length: 123456789 [content (123456789 bytes)] HTTP/1.1 104 Upload Resumption Supported Location: https://example.com/upload/0587fa44b HTTP/1.1 500 Internal Server Error D) The following example shows an upload creation being rejected by the server because the request content cannot be decoded. The "Upload-Complete" header in the response is set to true since the server is uninterested in receiving the full representation after the decoding failure, and the upload is complete in its perspective. The client cannot continue the upload. POST /upload-gzip HTTP/1.1 Host: example.com Upload-Complete: ?0 Content-Length: 23456789 Upload-Length: 123456789 Content-Encoding: gzip [corrupted gzip content] Kleidl, et al. Expires January 7, 2027 [Page 20] Internet-Draft Resumable Uploads July 2026 HTTP/1.1 104 Upload Resumption Supported Location: https://example.com/upload/6723cdf37 HTTP/1.1 400 Bad Request Upload-Complete: ?1 4.3. Offset Retrieval 4.3.1. Client Behavior If the client wants to resume the upload after an interruption, it has to know the amount of representation data processed by the upload resource so far. It can fetch the offset by sending a "HEAD" or "GET" request to the upload resource. Using "HEAD" is RECOMMENDED, since response content is not required for resumption. Upon a successful response, the client can continue the upload by appending representation data (Section 4.4) starting at the offset indicated by the "Upload-Offset" response header field. The offset can be less than or equal to the number of bytes of representation data that the client has already sent. The client is expected to handle backtracking of a reasonable length. On the other hand, the offset can be greater than the amount of sent representation data if the upload resource obtained additional representation data on behalf of the client. If the client is not able to provide the representation data at the given offset, the upload MUST be considered a failure. The client then MUST NOT continue the upload and SHOULD cancel the upload (Section 4.5). The client MUST NOT perform offset retrieval while creation (Section 4.2) or appending (Section 4.4) is in progress as this can cause the previous request to be terminated by the server as described in Section 4.6. If the client receives a 2xx successful response, the client can continue appending representation data to it and/or mark the upload as complete (Section 4.4). If the client receives a 4xx client error or 5xx server error response, or if it did not receive a response, the client MAY retry retrieving the offset. 4.3.2. Server Behavior A successful response to a "HEAD" or "GET" request against an upload resource Kleidl, et al. Expires January 7, 2027 [Page 21] Internet-Draft Resumable Uploads July 2026 o MUST include the offset in the "Upload-Offset" header field (Section 4.1.1), o MUST include the "Upload-Complete" header field (Section 4.1.2) indicating whether a final response was produced from processing the uploaded representation, o MUST include the representation's length in the "Upload-Length" header field, unless the client has not supplied the representation's length as described in (Section 4.1.3), o MUST indicate the limits in the "Upload-Limit" header field (Section 4.1.4), and o SHOULD include the "Cache-Control" header field with the value "no-store" to prevent HTTP caching ([CACHING]). The server SHOULD NOT generate a response with the "301 (Moved Permanently)", "302 (Found)", or "303 (See Other)" status codes because clients might follow the redirect without preserving the "HEAD" method. A client does not require response content for an offset retrieval request in order to successfully resume an upload. Therefore, serving response content for a "GET" request is unexpected. Its meaning is not defined by this protocol. 4.3.3. Examples The following example shows an offset retrieval request. The server indicates the current offset and that the upload is not complete yet. The client can continue to append representation data. HEAD /upload/c35e2cd29 HTTP/1.1 Host: example.com HTTP/1.1 204 No Content Upload-Complete: ?0 Upload-Offset: 25000000 Upload-Length: 100000000 Upload-Limit: max-age=3600 Cache-Control: no-store 4.4. Upload Append Kleidl, et al. Expires January 7, 2027 [Page 22] Internet-Draft Resumable Uploads July 2026 4.4.1. Client Behavior A client can continue the upload and append representation data by sending a "PATCH" request with the "application/partial-upload" media type (Section 6) to the upload resource. The request content is the representation data to append. The request can benefit from incremental delivery; see Section 11. The client MUST indicate the offset of the request content inside the representation data by including the "Upload-Offset" header field. To ensure that the upload resource will accept the request, the offset SHOULD be taken from an immediate previous response for retrieving the offset (Section 4.3) or appending representation data (Section 4.4). The request MUST include the "Upload-Complete" header field. Its value is true in two cases: o the request has content that is the end of the representation data. Once the content is fully processed by the server, the upload is complete. o the request has no content. Once the request is processed by the server, the upload is complete. This usage requires the full representation data to have been processed during prior requests. If the client received a final response with the "Upload-Complete: ?1" header field, the upload is complete and the corresponding response comes from the resource processing the representation according to the initial request (Section 4.1.2). Note that this does not necessarily indicate success. "4xx (Client Error)" or "5xx (Server Error)" status codes indicate in this case an error occurred while processing the representation, and therefore, resuming the upload would not resolve this error. If the client received a 4xx client error or 5xx server error final response with the "Upload-Complete" header field set to false or missing, or if it did not receive a final response, it can apply the heuristics described in Section 4.7 to retry or resume the upload. 4.4.2. Server Behavior A server applies a "PATCH" request with the "application/partial- upload" media type (Section 6) to an upload resource by appending the patch document in the request content. The server might not process the entire patch document when the upload is interrupted, for example because of a dropped connection or Kleidl, et al. Expires January 7, 2027 [Page 23] Internet-Draft Resumable Uploads July 2026 canceled request. In this case, the server SHOULD append as much of the patch document as possible to the upload resource, starting at its beginning and without discontinuities. Appending a continuous section starting at the patch document's beginning constitutes a successful PATCH as defined in Section 2 of [PATCH]. Saving the processed data allows the client to resume the upload from where it was interrupted. In addition, the upload resource MUST NOT be considered complete then. If the "Upload-Offset" request header field value does not match the current offset (Section 4.1.1), the server MUST reject the request with a "409 (Conflict)" status code and the "Upload-Complete" header field set to false. The response MUST include the correct offset in the "Upload-Offset" header field. The response can use the problem type [PROBLEM] of "https://iana.org/assignments/http-problem- types#mismatching-upload-offset" (Section 7.1). If the "Upload-Complete" request header field is set to true, the client intends to transfer the remaining representation data in one request. If the request content was fully processed, the upload is marked as complete and the server SHOULD generate the response that matches what the resource, that was targeted by the initial upload creation (Section 4.2), would have generated if it had processed the entire representation in the initial request. However, the response MUST include the "Upload-Complete" header field with a true value, allowing clients to identify whether a response, in particular error responses, is related to the resumable upload itself or the processing of the uploaded representation. If the "Upload-Complete" request header field is set to false, the client intends to transfer the remaining representation data over multiple requests. If the request content was fully processed, the server acknowledges the appended data by sending a "2xx (Successful)" response with the "Upload-Complete" header field set to false. Even if the upload is complete (Section 4.1.2) in the server's perspective and the final response from the targeted resource has already been sent, the client might still perform an upload append (Section 4.4) after an offset retrieval (Section 4.3) due to the response being lost during transmission. The server can choose to replay the final response to the client if the request to append to the completed upload is valid. The server MUST record the representation's length according to Section 4.1.3 if the "Upload-Length" or "Upload-Complete" header fields are included in the request. If the representation's length is known, the server MUST prevent the offset from exceeding the representation's length by rejecting the request once the offset Kleidl, et al. Expires January 7, 2027 [Page 24] Internet-Draft Resumable Uploads July 2026 exceeds the length, marking the upload resource invalid and rejecting any further interaction with it. It is not sufficient to rely on the "Content-Length" header field for enforcement because this header field might not be present. While the request content is being processed, the server SHOULD send interim responses with a "104 (Upload Resumption Supported)" status code and the "Upload-Offset" header field set to the current offset to inform the client about the upload progress. These interim responses MUST NOT include the "Location" header field. The server SHOULD include the "Upload-Complete" (Section 4.1.2) header field in the response to indicate whether it is the result of processing the uploaded representation. The server SHOULD NOT generate a response with the "301 (Moved Permanently)", "302 (Found)", or "303 (See Other)" status codes and the "Upload-Complete: ?0" header field because clients might follow the redirect without preserving the "PATCH" method. 4.4.3. Examples A) The following example shows an upload append request. The client transfers the next 3456789 bytes at an offset of 20000000 and does not indicate that the upload is then completed. The server generates one interim response, when the offset reached 21728394 bytes, and finally acknowledges the new offset: PATCH /upload/37a504d87 HTTP/1.1 Host: example.com Upload-Complete: ?0 Upload-Offset: 20000000 Content-Length: 3456789 Content-Type: application/partial-upload [content (3456789 bytes)] HTTP/1.1 104 Upload Resumption Supported Upload-Offset: 21728394 HTTP/1.1 204 No Content Upload-Complete: ?0 B) The next example shows an upload append, where the client transfers the remaining 4567890 bytes and completes the upload with a length of 1234567890 bytes. The server processes the uploaded representation and generates the corresponding response, in this example containing extracted meta data: Kleidl, et al. Expires January 7, 2027 [Page 25] Internet-Draft Resumable Uploads July 2026 PATCH /upload/d38d6ffe8 HTTP/1.1 Host: example.com Upload-Complete: ?1 Upload-Offset: 1230000000 Content-Length: 4567890 Content-Type: application/partial-upload [content (4567890 bytes)] HTTP/1.1 200 OK Upload-Complete: ?1 Content-Type: application/json { "metadata": { [...] } } 4.5. Upload Cancellation 4.5.1. Client Behavior If the client wants to terminate the transfer without the ability to resume, it can send a "DELETE" request to the upload resource. Doing so is an indication that the client is no longer interested in continuing the upload, and that the server can release any resources associated with it. 4.5.2. Server Behavior Upon receiving a "DELETE" request, the server SHOULD deactivate the upload resource. The server SHOULD terminate any in-flight requests to the upload resource before sending the response by abruptly terminating their HTTP connection(s) or stream(s) as described in Section 4.6. The server SHOULD NOT generate a response with the "301 (Moved Permanently)", "302 (Found)", or "303 (See Other)" status codes because clients might follow the redirect without preserving the "DELETE" method. 4.5.3. Example The following example shows an upload cancellation: Kleidl, et al. Expires January 7, 2027 [Page 26] Internet-Draft Resumable Uploads July 2026 DELETE /upload/5688a431c HTTP/1.1 Host: example.com HTTP/1.1 204 No Content 4.6. Concurrency Resumable uploads, as defined in this document, do not permit uploading representation data in parallel to the same upload resource. The client MUST NOT perform multiple representation data transfers for the same upload resource in parallel. Even if the client is well-behaved and doesn't send concurrent requests, network interruptions can occur in such a way that the client considers a request as failed while the server is unaware of the problem and considers the request still ongoing. The client might then try to resume the upload with the best intentions, resulting in concurrent requests from the server's perspective. Therefore, the server MUST take measures to prevent race conditions, data loss and corruption from concurrent requests to append representation data (Section 4.4) and/or cancellation (Section 4.5) to the same upload resource. In addition, the server MUST NOT send outdated information in responses when retrieving the offset (Section 4.3). This means that the offset sent by the server MUST be accepted in a subsequent request to append representation data if no other request to append representation data or cancel was received in the meantime. In other words, clients have to be able to use received offsets. The RECOMMENDED approach is as follows: If a server receives a new request to retrieve the offset (Section 4.3), append representation data (Section 4.4), or cancel the upload (Section 4.5) while a previous request for creating the upload (Section 4.2) or appending representation data (Section 4.4) to the same upload resource is still ongoing, the server SHOULD prevent race conditions, data loss, and corruption by terminating the previous request before processing the new request. Due to network delay and reordering, the server might still be receiving representation data from an ongoing transfer for the same upload resource, which in the client's perspective has failed. Since the client is not allowed to perform multiple transfers for the same upload resource in parallel, the server can assume that the previous attempt has already failed. Therefore, the server MAY abruptly terminate the previous HTTP connection or stream. Since implementing this approach is not always technically possible or feasible, other measures can be considered as well. A simpler approach is that the server only processes a new request to retrieve the offset (Section 4.3), append representation data (Section 4.4), Kleidl, et al. Expires January 7, 2027 [Page 27] Internet-Draft Resumable Uploads July 2026 or cancellation (Section 4.5) once all previous requests have been processed. This effectively implements exclusive access to the upload resource through an access lock. However, since network interruptions can occur in ways that cause the request to hang from the server's perspective, it might take the server significant time to realize the interruption and time out the request. During this period, the client will be unable to access the resource and resume the upload, causing friction for the end users. Therefore, the recommended approach is to terminate previous requests to enable quick resumption of uploads. 4.7. Retry If the client received a 4xx client error or 5xx server error response with the "Upload-Complete" header field set to false or missing when creating the upload resource (Section 4.2) or appending to it (Section 4.4), it can apply the heuristics described below to retry or resume the upload. o "409 (Conflict)" with the "Upload-Complete" header field set to false can be resumed with the correct offset (Section 4.1.1). If no "Upload-Offset" header field is provided, the client SHOULD retrieve the offset (Section 4.3) before resuming. o "413 (Content Too Large)" can be resumed after applying appropriate limits (Section 4.1.4). o "429 (Too Many Requests)" can be retried after appropriate delays. o "5xx (Server Error)" status codes can be retried. If no final response was received at all due to connectivity issues, the client MAY automatically attempt upload resumption by retrieving the current offset (Section 4.3). The client SHOULD limit the number of retries it performs before considering the upload a failure. 5. Status Code 104 (Upload Resumption Supported) The "104 (Upload Resumption Supported)" status code can be used for two purposes: o When responding to requests to create uploads, an interim response with the "104 (Upload Resumption Supported)" status code can be sent to indicate the resource's support for resumable uploads, as well as the URI and limits of the corresponding upload resource in the "Location" and "Upload-Limit" header fields, respectively (see Kleidl, et al. Expires January 7, 2027 [Page 28] Internet-Draft Resumable Uploads July 2026 Section 4.2). This notifies the client early about the ability to resume the upload in case of network interruptions. o While processing the content of a request to append representation data or create an upload, the server can regularly send interim responses with the "104 (Upload Resumption Supported)" status code to indicate the current upload progress in the "Upload-Offset" header field (see Section 4.2 and Section 4.4). This allows the client to show more accurate progress information about the amount of data processed by the server. In addition, clients can use this information to release representation data that was buffered, knowing that it doesn't have to be retransmitted. When creating or appending resumable uploads, the client can generate a 100-continue expectation because it wants an indication that the resource is willing to accept the upload. The client MAY treat an interim response with the "104 (Upload Resumption Supported)" status code as fulfilling the 100-continue expectation and start sending the request content. However, the server MUST NOT omit the "100 (Continue)" response because it has sent an interim response with the "104 (Upload Resumption Supported)" status code. 6. Media Type application/partial-upload The "application/partial-upload" media type describes a contiguous block from the representation data that should be uploaded to a resource. There is no minimum block size and the block might be empty. The block can be a subset of the representation data, where the start and/or end of the block don't line up with the start and/or end of the representation data respectively. 7. Problem Types 7.1. Mismatching Offset This section defines the "https://iana.org/assignments/http-problem- types#mismatching-upload-offset" problem type [PROBLEM]. A server can use this problem type when responding to an upload append request (Section 4.4) to indicate that the "Upload-Offset" header field in the request does not match the upload resource's offset. Two problem type extension members are defined: the "expected-offset" and "provided-offset" members. A response using this problem type SHOULD populate both members, with the value of "expected-offset" taken from the upload resource and the value of "provided-offset" taken from the upload append request. Kleidl, et al. Expires January 7, 2027 [Page 29] Internet-Draft Resumable Uploads July 2026 The following example shows an example response, where the resource's offset was 12500000, but the client attempted to append at offset 25000000: # NOTE: '\' line wrapping per RFC 8792 HTTP/1.1 409 Conflict Content-Type: application/problem+json Upload-Offset: 12500000 Upload-Complete: ?0 { "type":"https://iana.org/assignments/http-problem-types#\ mismatching-upload-offset", "title": "offset from request does not match offset of resource", "expected-offset": 12500000, "provided-offset": 25000000 } 7.2. Inconsistent Length This section defines the "https://iana.org/assignments/http-problem- types#inconsistent-upload-length" problem type [PROBLEM]. A server can use this problem type when responding to an upload creation (Section 4.2) or upload append request (Section 4.4) to indicate that the request includes inconsistent length values, as described in Section 4.1.3. The following example shows an example response: # NOTE: '\' line wrapping per RFC 8792 HTTP/1.1 400 Bad Request Content-Type: application/problem+json Upload-Complete: ?0 { "type":"https://iana.org/assignments/http-problem-types#\ inconsistent-upload-length", "title": "inconsistent length values for upload" } 8. Content Codings Since the codings listed in "Content-Encoding" are a characteristic of the representation (see Section 8.4 of [HTTP]), both the client and the server always compute the values for "Upload-Offset" and optionally "Upload-Length" on the content coded data (that is, the Kleidl, et al. Expires January 7, 2027 [Page 30] Internet-Draft Resumable Uploads July 2026 representation data). Moreover, the content codings are retained throughout the entire upload, meaning that the server is not required to decode the representation data to support resumable uploads. See Appendix A of [DIGEST-FIELDS] for more information. 9. Transfer Codings Unlike "Content-Encoding" (see Section 8.4.1 of [HTTP]), "Transfer- Encoding" (see Section 6.1 of [RFC9112]) is a property of the message, not of the representation. Moreover, transfer codings can be applied in transit (e.g., by proxies). This means that a client does not have to consider the transfer codings to compute the upload offset, while a server is responsible for transfer decoding the message before computing the upload offset. The same applies to the value of "Upload-Length". Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer- Encoding" header field. 10. Upload Strategies The definition of the upload creation request (Section 4.2) provides the client with flexibility to choose whether the representation data is fully or partially transferred in the first request, or if no representation data is included at all. Which behavior is best largely depends on the client's capabilities, its desire to avoid data retransmission, and its knowledge about the resource's support for resumable uploads. The following subsections describe two typical upload strategies that are suited for common environments. Note that these modes are never explicitly communicated to the server and clients are not required to stick to one strategy, but can mix and adapt them to their needs. 10.1. Optimistic Upload Creation An "optimistic upload creation" can be used independent of the client's knowledge about the resource's support for resumable uploads. However, the client must be capable of handling and processing interim responses. An upload creation request then includes the full representation data because the client anticipates that it will be transferred without interruptions or resumed if an interruption occurs. The benefit of this method is that if the upload creation request succeeded, the representation data was transferred in a single request without additional round trips. Kleidl, et al. Expires January 7, 2027 [Page 31] Internet-Draft Resumable Uploads July 2026 A possible drawback is that the client might be unable to resume an upload. If an upload is interrupted before the client receives a "104 (Upload Resumption Supported)" interim response with the upload resource's URI, the client cannot resume that upload due to the missing URI. The interim response might not be received if the interruption happens too early in the message exchange, the resource targeted in the initial request does not support resumable uploads, the server is not capable of sending the "104 (Upload Resumption Supported)" interim response, or an intermediary dropped the interim response. Without a 104 response, the client needs to either treat the upload as failed or retry the entire upload creation request if this is allowed by the application. A client might wait for a limited duration to receive a 104 (Upload Resumption Supported) interim response before starting to transmit the request content. This way, the client can learn about the resource's support for resumable uploads and/or the upload resource's URI. This is conceptually similar to how a client might wait for a 100 (Continue) interim response (see Section 10.1.1 of [HTTP]) before committing to work. 10.1.1. Upgrading To Resumable Uploads Optimistic upload creation allows clients and servers to automatically upgrade non-resumable uploads to resumable ones. In a non-resumable upload, the representation is transferred in a single request, usually "POST" or "PUT", without any ability to resume from interruptions. The client can invite the server to upgrade such a request to a resumable upload by adding the "Upload-Complete: ?1" header field to the original request. The "Upload-Length" header field SHOULD be added if the representation's length is known upfront. The request is not changed otherwise. If the resource targeted in the initial request supports resumable uploads, the server can create an upload resource and send its URI in a "104 (Upload Resumption Supported)" interim response for the client to resume the upload after interruptions. A resource that does not support resumable uploads or does not want to upgrade to a resumable upload for this request ignores the "Upload-Complete: ?1" header. The transfer then falls back to a non-resumable upload without additional cost. This upgrade can also be performed transparently by a library or program that acts as an HTTP client by sending requests on behalf of a user. When the user instructs the client to send a non-resumable request, the client can perform the upgrade transparently and handle potential interruptions and resumptions under the hood without involving the user. The last response received by the client is Kleidl, et al. Expires January 7, 2027 [Page 32] Internet-Draft Resumable Uploads July 2026 considered the response for the entire upload and should be provided to the user. 10.2. Careful Upload Creation For a "careful upload creation" the client knows that the resource targeted in the initial request supports resumable uploads and sends an empty upload creation request without including any representation data. Upon successful response reception, the client can use the included upload resource URI to transmit the representation data (Section 4.4) and resume the upload at any stage if an interruption occurs. The client should inspect the response for the "Upload- Limit" header field, which would indicate limits applying to the remaining upload procedure. The retransmission of representation data or the ultimate upload failure that can happen with an "optimistic upload creation" is therefore avoided at the expense of an additional request that does not carry representation data. This approach is best suited if the client cannot receive interim responses, e.g., due to a limitation in the provided HTTP interface, or if large representations are transferred where the cost of the additional request is minuscule compared to the effort of transferring the representation itself. 11. Incremental Transfer, Processing and Forwarding The resumable upload design is most effective when a server processes request message portions as they arrive, which ensures the greatest chance that data is processed before a possible transfer interruption. To support incremental processing, it is RECOMMENDED that clients send request content incrementally and minimize buffering. As described in [INCREMENTAL], intermediaries might interfere with the incremental delivery of data to a server. Clients can use the "Incremental" header field defined in Section 3 of [INCREMENTAL] to signal their preference for incremental forwarding by intermediaries. 12. Request Cancellation A client or server might want to interrupt an in-flight message transfer intentionally for various reasons (see Section 1). The mechanism to do so depends on the HTTP version in use: Kleidl, et al. Expires January 7, 2027 [Page 33] Internet-Draft Resumable Uploads July 2026 HTTP/1.1: close the underlying transport connection (Section 9.5 of [RFC9112]) HTTP/2: send a "RST_STREAM" frame (Section 6.4 of [RFC9113]) HTTP/3: send a "RESET_STREAM" (Section 19.4 of [QUIC]) or "STOP_SENDING" frame (Section 19.5 of [QUIC]) Version-specific mechanisms place requirements on clients or servers for actioning the cancellation. However, for all versions of HTTP, resumable uploads allow the server to process received representation data and expose the upload offset via the upload resource, enabling continuation of the upload after interruption. 13. Security Considerations The upload resource URI is the identifier used for modifying the upload. Without further protection of this URI, an attacker may obtain information about an upload, append data to it, or cancel it. To prevent this, the server SHOULD ensure that only authorized clients can access the upload resource. To reduce the risk of unauthorized access, it is RECOMMENDED to generate upload resource URIs in such a way that makes it hard to be guessed by unauthorized clients. In addition, servers may embed information about the storage or processing location of the uploaded representation in the upload resource URI to make routing requests more efficient. If so, they MUST ensure that no internal information is leaked in the URI that is not intended to be exposed. Uploaded representation data and its metadata are untrusted input. Server operators have to be careful of where uploaded data is written and subsequently accessed, especially if the operations cause the representation to be processed or executed by the server. In addition, metadata MUST be validated and/or sanitized if the server takes its values into consideration for processing or storing the representation. Some servers or intermediaries provide scanning of content uploaded by clients. Any scanning mechanism that relies on receiving a complete representation in a single request message can be defeated by resumable uploads because content can be split across multiple messages. Servers or intermediaries wishing to perform content scanning SHOULD consider how resumable uploads can circumvent scanning and take appropriate measures. Possible strategies include waiting for the upload to complete before scanning the entire representation, or disabling resumable uploads. Kleidl, et al. Expires January 7, 2027 [Page 34] Internet-Draft Resumable Uploads July 2026 There can be a significant delay between the creation of an upload resource and its completion. Policy decisions or authorization checks performed on the initial request might become outdated or invalid by the time the upload completes. To mitigate vulnerabilities arising from time-of-check to time-of-use (TOCTOU) conditions, the server SHOULD validate that the user is still allowed to perform the requested action before finalizing the upload. This includes, for example, validating access privileges and quota policies associated with the upload resource. Resumable uploads are vulnerable to Slowloris-style attacks [SLOWLORIS]. A malicious client may create upload resources and keep them alive by regularly sending "PATCH" requests with no or small content to the upload resources. This could be abused to exhaust server resources by creating and holding open uploads indefinitely with minimal work. Servers SHOULD provide mitigations for Slowloris attacks, such as increasing the maximum number of clients the server will allow, limiting the number of uploads a single client is allowed to make, imposing restrictions on the minimum transfer speed an upload is allowed to have, and restricting the length of time an upload resource can exist. Uploads performed as a series of appends can be used to upload data up to the "max-size" limit, which could be a larger size than a server or intermediary might normally permit in conventional single upload request message content. Servers or intermediaries need to consider that relying solely on message content limits to constrain resources allocated to uploads might not be an effective strategy when using resumable uploads. 14. IANA Considerations 14.1. HTTP Fields IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry": Kleidl, et al. Expires January 7, 2027 [Page 35] Internet-Draft Resumable Uploads July 2026 +-----------------+-----------+-------------+-----------------------+ | Field Name | Status | Structured | Reference | | | | Type | | +-----------------+-----------+-------------+-----------------------+ | Upload-Offset | permanent | Item | Section 4.1.1 of this | | | | | document | | | | | | | Upload-Complete | permanent | Item | Section 4.1.2 of this | | | | | document | | | | | | | Upload-Length | permanent | Item | Section 4.1.3 of this | | | | | document | | | | | | | Upload-Limit | permanent | Dictionary | Section 4.1.4 of this | | | | | document | +-----------------+-----------+-------------+-----------------------+ 14.2. HTTP Status Code IANA is asked to register the following entry in the "HTTP Status Codes" registry: Value: 104 (suggested value) Description: Upload Resumption Supported Specification: Section 5 of this document 14.3. Media Type IANA is asked to register the following entry in the "Media Types" registry: Type name: application Subtype name: partial-upload Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: see Section 13 of this document Interoperability considerations: N/A Published specification: Section 6 of this document Kleidl, et al. Expires January 7, 2027 [Page 36] Internet-Draft Resumable Uploads July 2026 Applications that use this media type: Applications that transfer files over unreliable networks or want pause- and resumable uploads. Fragment identifier considerations: N/A Additional information: o Deprecated alias names for this type: N/A o Magic number(s): N/A o File extension(s): N/A o Macintosh file type code(s): N/A o Windows Clipboard Name: N/A Person and email address to contact for further information: See the Authors' Addresses section of this document. Intended usage: COMMON Restrictions on usage: N/A Author: See the Authors' Addresses section of this document. Change controller: IETF 14.4. HTTP Problem Types IANA is asked to register the following entry in the "HTTP Problem Types" registry: Type URI: https://iana.org/assignments/http-problem- types#mismatching-upload-offset Title: Mismatching Upload Offset Recommended HTTP status code: 409 Reference: Section 7.1 of this document IANA is asked to register the following entry in the "HTTP Problem Types" registry: Type URI: https://iana.org/assignments/http-problem- types#inconsistent-upload-length Kleidl, et al. Expires January 7, 2027 [Page 37] Internet-Draft Resumable Uploads July 2026 Title: Inconsistent Upload Length Values Recommended HTTP status code: 400 Reference: Section 7.2 of this document 15. References 15.1. Normative References [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . [CONTENT-DISPOSITION] Reschke, J., "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)", RFC 6266, DOI 10.17487/RFC6266, June 2011, . [DIGEST-FIELDS] Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, . [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [PATCH] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010, . [PROBLEM] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Kleidl, et al. Expires January 7, 2027 [Page 38] Internet-Draft Resumable Uploads July 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, . [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, . [STRUCTURED-FIELDS] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, . 15.2. Informative References [INCREMENTAL] Oku, K., Pauly, T., and M. Thomson, "Incremental Forwarding of HTTP Messages", draft-ietf-httpbis- incremental-04 (work in progress), March 2026. [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . [SLOWLORIS] "RSnake" Hansen, R., "Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client!", June 2009, . 15.3. URIs [1] https://tus.io/ Appendix A. Changes This section is to be removed before publishing as an RFC. A.1. Since draft-ietf-httpbis-resumable-upload-11 o Clear up different responsibilities of server and upload resource. o Relax recommendations on client handling greater offsets. Kleidl, et al. Expires January 7, 2027 [Page 39] Internet-Draft Resumable Uploads July 2026 o Clarify client behavior for 413 responses. o Remove Accept-Patch from OPTIONS responses. o Allow upload creation requests with no content regardless of the "min-append-size" limit. o Remove nominative languages addressing the lost final response. o Allow "max-age" limit to decrease as expected. o Redefine Upload-Complete on the server side. o Recommend incremental delivery. o Clarify "min-size" limit and its client behavior. o Describe "GET" requests against upload resource. o Replace uses of term "upload length" with "representation's length". o Include "Upload-Limit" in response to limit violation. o Clarify that clients might not know limits when starting upload. o Remove section covering integrity digests. o Increase the draft interop version. o Add version-specific details on cancelling in-flight transfers. o Clarify client retry strategies. A.2. Since draft-ietf-httpbis-resumable-upload-10 o Add recommended disposition type for file name indication. A.3. Since draft-ietf-httpbis-resumable-upload-09 o Requires Accept-Patch in OPTIONS. o Add security consideration regarding time-of-check to time-of-use. o Lift requirement on Upload-Complete for all final responses. o Relax requirements on limit changes. Kleidl, et al. Expires January 7, 2027 [Page 40] Internet-Draft Resumable Uploads July 2026 o Describe the interaction between 100 and 104 responses. o Numerous editorial improvements. A.4. Since draft-ietf-httpbis-resumable-upload-08 o Clarify definitions of new header fields. o Make handling of OPTIONS * optional. o Require server to announce limits using Upload-Limit. o Require clients to adhere to known limits. o Rephrase requirements for concurrency handling, focusing on the outcome. o Remove requirement for 204 status code for DELETE responses. o Increase the draft interop version. o Add section about 104 status code. o Rephrase recommendation for sending information back to client. A.5. Since draft-ietf-httpbis-resumable-upload-07 o Clarify server handling when upload length is exceeded. o Extend security considerations about upload resource URIs, representation metadata, and untrusted inputs. o Allow clients to retry for appropriate 4xx responses. A.6. Since draft-ietf-httpbis-resumable-upload-06 o Minor editorial improvements to introduction and examples. o Define structured types for new header fields. A.7. Since draft-ietf-httpbis-resumable-upload-05 o Increase the draft interop version. o Numerous editorial changes. o Rename "expires" limit to "max-age". Kleidl, et al. Expires January 7, 2027 [Page 41] Internet-Draft Resumable Uploads July 2026 o Require "Upload-Complete", but not "Upload-Offset" or "Upload- Limit", for append responses. o Add problem type for inconsistent length values. o Reduce use of "file" in favor of "representation". A.8. Since draft-ietf-httpbis-resumable-upload-04 o Clarify implications of "Upload-Limit" header. o Allow client to fetch upload limits upfront via "OPTIONS". o Add guidance on upload creation strategy. o Add "Upload-Length" header to indicate length during creation. o Describe possible usage of "Want-Repr-Digest". A.9. Since draft-ietf-httpbis-resumable-upload-03 o Add note about "Content-Location" for referring to subsequent resources. o Require "application/partial-upload" for appending to uploads. o Explain handling of content and transfer codings. o Add problem types for mismatching offsets and completed uploads. o Clarify that completed uploads must not be appended to. o Describe interaction with Digest Fields from RFC9530. o Require that upload offset does not decrease over time. o Add Upload-Limit header field. o Increase the draft interop version. A.10. Since draft-ietf-httpbis-resumable-upload-02 o Add upload progress notifications via informational responses. o Add security consideration regarding request filtering. o Explain the use of empty requests for creation uploads and appending. Kleidl, et al. Expires January 7, 2027 [Page 42] Internet-Draft Resumable Uploads July 2026 o Extend security consideration to include resource exhaustion attacks. o Allow 200 status codes for offset retrieval. o Increase the draft interop version. A.11. Since draft-ietf-httpbis-resumable-upload-01 o Replace Upload-Incomplete header with Upload-Complete. o Replace terminology about procedures with HTTP resources. o Increase the draft interop version. A.12. Since draft-ietf-httpbis-resumable-upload-00 o Remove Upload-Token and instead use Server-generated upload URL for upload identification. o Require the Upload-Incomplete header field in Upload Creation Procedure. o Increase the draft interop version. A.13. Since draft-tus-httpbis-resumable-uploads-protocol-02 None A.14. Since draft-tus-httpbis-resumable-uploads-protocol-01 o Clarifying backtracking and preventing skipping ahead during the Offset Receiving Procedure. o Clients auto-retry 404 is no longer allowed. A.15. Since draft-tus-httpbis-resumable-uploads-protocol-00 o Split the Upload Transfer Procedure into the Upload Creation Procedure and the Upload Appending Procedure. Appendix B. Draft Version Identification This section is to be removed before publishing as an RFC. To assist the development of implementations and interoperability testing while this document is still a draft, an interop version is defined. Implementations of this draft use the interop version to Kleidl, et al. Expires January 7, 2027 [Page 43] Internet-Draft Resumable Uploads July 2026 identify the iteration of the draft that they implement. The interop version is bumped for breaking changes. The current interop version is 9. Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version as its value to its requests. The "Upload-Draft-Interop-Version" field value is an Integer. Server implementations of draft versions of the protocol MUST NOT send a "104 (Upload Resumption Supported)" interim response when the interop version indicated by the "Upload-Draft-Interop-Version" header field in the request is missing or mismatching. Server implementations of draft versions of the protocol MUST also send a header field "Upload-Draft-Interop-Version" with the interop version as its value to the "104 (Upload Resumption Supported)" interim response. Client implementations of draft versions of the protocol MUST ignore a "104 (Upload Resumption Supported)" interim response with missing or mismatching interop version indicated by the "Upload-Draft- Interop-Version" header field. The reason both the client and the server are sending and checking the draft version is to ensure that implementations of the final RFC will not accidentally interop with draft implementations, as they will not check the existence of the "Upload-Draft-Interop-Version" header field. Acknowledgments This document is based on an Internet-Draft specification written by Jiten Mehta, Stefan Matsson, and the authors of this document. The tus v1 protocol [1] is a specification for a resumable file upload protocol over HTTP. It inspired the early design of this protocol. Members of the tus community helped significantly in the process of bringing this work to the IETF. The authors would like to thank Mark Nottingham for substantive contributions to the text, along with the following in alphabetical order for their thorough reviews of the document: o Daniel Resnick o Glenn Strauss Kleidl, et al. Expires January 7, 2027 [Page 44] Internet-Draft Resumable Uploads July 2026 o Grant Gryczan o Julian Reschke o Mert Alev o Mike Bishop o Roy T. Fielding o Willy Tarreau Authors' Addresses Marius Kleidl (editor) Transloadit Email: marius@transloadit.com Guoye Zhang (editor) Apple Inc. Email: guoye_zhang@apple.com Lucas Pardue (editor) Cloudflare Email: lucas@lucaspardue.com Kleidl, et al. Expires January 7, 2027 [Page 45]