draft-ietf-httpbis-resumable-upload-12.txt   draft-ietf-httpbis-resumable-upload-latest.txt 
HTTP Working Group M. Kleidl, Ed. HTTP Working Group M. Kleidl, Ed.
Internet-Draft Transloadit Internet-Draft Transloadit
Intended status: Standards Track G. Zhang, Ed. Intended status: Standards Track G. Zhang, Ed.
Expires: January 7, 2027 Apple Inc. Expires: April 3, 2027 Apple Inc.
L. Pardue, Ed. L. Pardue, Ed.
Cloudflare Cloudflare
July 6, 2026 September 30, 2026
Resumable Uploads for HTTP Resumable Uploads for HTTP
draft-ietf-httpbis-resumable-upload-12 draft-ietf-httpbis-resumable-upload-latest
Abstract Abstract
HTTP data transfers can encounter interruption due to reasons such as HTTP data transfers can encounter interruption due to reasons such as
canceled requests or dropped connections. If the intended recipient canceled requests or dropped connections. If the intended recipient
can indicate how much of the data was processed prior to can indicate how much of the data was processed prior to
interruption, a sender can resume data transfer at that point instead interruption, a sender can resume data transfer at that point instead
of attempting to transfer all of the data again. HTTP range requests of attempting to transfer all of the data again. HTTP range requests
support this concept of resumable downloads from server to client. support this concept of resumable downloads from server to client.
This document describes a mechanism that supports resumable uploads This document describes a mechanism that supports resumable uploads
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2027. This Internet-Draft will expire on April 3, 2027.
Copyright Notice Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example 1: Complete upload of representation data with 3.1. Example 1: Complete upload of representation data with
known size . . . . . . . . . . . . . . . . . . . . . . . 6 known size . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Example 2: Upload as a series of parts . . . . . . . . . 8 3.2. Example 2: Upload as a series of parts . . . . . . . . . 8
4. Upload Resource . . . . . . . . . . . . . . . . . . . . . . . 10 4. Upload Resource . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. State . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. State . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Offset . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Offset . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Completeness . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Completeness . . . . . . . . . . . . . . . . . . . . 12
4.1.3. Length . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.3. Length . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.4. Limits . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. Limits . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Upload Creation . . . . . . . . . . . . . . . . . . . . . 16 4.2. Upload Creation . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 16 4.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 16
4.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 17 4.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 18
4.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 19 4.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Offset Retrieval . . . . . . . . . . . . . . . . . . . . 21 4.3. Offset Retrieval . . . . . . . . . . . . . . . . . . . . 21
4.3.1. Client Behavior . . . . . . . . . . . . . . . . . . . 21 4.3.1. Client Behavior . . . . . . . . . . . . . . . . . . . 21
4.3.2. Server Behavior . . . . . . . . . . . . . . . . . . . 21 4.3.2. Server Behavior . . . . . . . . . . . . . . . . . . . 22
4.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 22 4.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 22
4.4. Upload Append . . . . . . . . . . . . . . . . . . . . . . 22 4.4. Upload Append . . . . . . . . . . . . . . . . . . . . . . 23
4.4.1. Client Behavior . . . . . . . . . . . . . . . . . . . 23 4.4.1. Client Behavior . . . . . . . . . . . . . . . . . . . 23
4.4.2. Server Behavior . . . . . . . . . . . . . . . . . . . 23 4.4.2. Server Behavior . . . . . . . . . . . . . . . . . . . 24
4.4.3. Examples . . . . . . . . . . . . . . . . . . . . . . 25 4.4.3. Examples . . . . . . . . . . . . . . . . . . . . . . 25
4.5. Upload Cancellation . . . . . . . . . . . . . . . . . . . 26 4.5. Upload Cancellation . . . . . . . . . . . . . . . . . . . 26
4.5.1. Client Behavior . . . . . . . . . . . . . . . . . . . 26 4.5.1. Client Behavior . . . . . . . . . . . . . . . . . . . 26
4.5.2. Server Behavior . . . . . . . . . . . . . . . . . . . 26 4.5.2. Server Behavior . . . . . . . . . . . . . . . . . . . 27
4.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 26 4.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 27
4.6. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 27 4.6. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 27
4.7. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.7. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5. Status Code 104 (Upload Resumption Supported) . . . . . . . . 28 5. Status Code 104 (Upload Resumption Supported) . . . . . . . . 29
6. Media Type application/partial-upload . . . . . . . . . . . . 29 6. Media Type application/partial-upload . . . . . . . . . . . . 30
7. Problem Types . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Problem Types . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Mismatching Offset . . . . . . . . . . . . . . . . . . . 29 7.1. Mismatching Offset . . . . . . . . . . . . . . . . . . . 30
7.2. Inconsistent Length . . . . . . . . . . . . . . . . . . . 30 7.2. Inconsistent Length . . . . . . . . . . . . . . . . . . . 31
8. Content Codings . . . . . . . . . . . . . . . . . . . . . . . 30 8. Content Codings . . . . . . . . . . . . . . . . . . . . . . . 31
9. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 31 9. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 31
10. Upload Strategies . . . . . . . . . . . . . . . . . . . . . . 31 10. Upload Strategies . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Optimistic Upload Creation . . . . . . . . . . . . . . . 31 10.1. Optimistic Upload Creation . . . . . . . . . . . . . . . 32
10.1.1. Upgrading To Resumable Uploads . . . . . . . . . . . 32 10.1.1. Upgrading To Resumable Uploads . . . . . . . . . . . 33
10.2. Careful Upload Creation . . . . . . . . . . . . . . . . 33 10.2. Careful Upload Creation . . . . . . . . . . . . . . . . 33
11. Incremental Transfer, Processing and Forwarding . . . . . . . 33 11. Incremental Transfer, Processing and Forwarding . . . . . . . 34
12. Request Cancellation . . . . . . . . . . . . . . . . . . . . 33 12. Request Cancellation . . . . . . . . . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 13.1. Different Origins . . . . . . . . . . . . . . . . . . . 36
14.1. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . 35 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
14.2. HTTP Status Code . . . . . . . . . . . . . . . . . . . . 36 14.1. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . 36
14.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 36 14.2. HTTP Status Code . . . . . . . . . . . . . . . . . . . . 37
14.4. HTTP Problem Types . . . . . . . . . . . . . . . . . . . 37 14.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 37
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 14.4. HTTP Problem Types . . . . . . . . . . . . . . . . . . . 38
15.1. Normative References . . . . . . . . . . . . . . . . . . 38 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
15.2. Informative References . . . . . . . . . . . . . . . . . 39 15.1. Normative References . . . . . . . . . . . . . . . . . . 39
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 39 15.2. Informative References . . . . . . . . . . . . . . . . . 40
A.1. Since draft-ietf-httpbis-resumable-upload-11 . . . . . . 39 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 41
A.2. Since draft-ietf-httpbis-resumable-upload-10 . . . . . . 40 A.1. Since draft-ietf-httpbis-resumable-upload-12 . . . . . . 41
A.3. Since draft-ietf-httpbis-resumable-upload-09 . . . . . . 40 A.2. Since draft-ietf-httpbis-resumable-upload-11 . . . . . . 41
A.4. Since draft-ietf-httpbis-resumable-upload-08 . . . . . . 41 A.3. Since draft-ietf-httpbis-resumable-upload-10 . . . . . . 42
A.5. Since draft-ietf-httpbis-resumable-upload-07 . . . . . . 41 A.4. Since draft-ietf-httpbis-resumable-upload-09 . . . . . . 42
A.6. Since draft-ietf-httpbis-resumable-upload-06 . . . . . . 41 A.5. Since draft-ietf-httpbis-resumable-upload-08 . . . . . . 42
A.7. Since draft-ietf-httpbis-resumable-upload-05 . . . . . . 41 A.6. Since draft-ietf-httpbis-resumable-upload-07 . . . . . . 43
A.8. Since draft-ietf-httpbis-resumable-upload-04 . . . . . . 42 A.7. Since draft-ietf-httpbis-resumable-upload-06 . . . . . . 43
A.9. Since draft-ietf-httpbis-resumable-upload-03 . . . . . . 42 A.8. Since draft-ietf-httpbis-resumable-upload-05 . . . . . . 43
A.10. Since draft-ietf-httpbis-resumable-upload-02 . . . . . . 42 A.9. Since draft-ietf-httpbis-resumable-upload-04 . . . . . . 43
A.11. Since draft-ietf-httpbis-resumable-upload-01 . . . . . . 43 A.10. Since draft-ietf-httpbis-resumable-upload-03 . . . . . . 43
A.12. Since draft-ietf-httpbis-resumable-upload-00 . . . . . . 43 A.11. Since draft-ietf-httpbis-resumable-upload-02 . . . . . . 44
A.13. Since draft-tus-httpbis-resumable-uploads-protocol-02 . . 43 A.12. Since draft-ietf-httpbis-resumable-upload-01 . . . . . . 44
A.14. Since draft-tus-httpbis-resumable-uploads-protocol-01 . . 43 A.13. Since draft-ietf-httpbis-resumable-upload-00 . . . . . . 44
A.15. Since draft-tus-httpbis-resumable-uploads-protocol-00 . . 43 A.14. Since draft-tus-httpbis-resumable-uploads-protocol-02 . . 45
Appendix B. Draft Version Identification . . . . . . . . . . . . 43 A.15. Since draft-tus-httpbis-resumable-uploads-protocol-01 . . 45
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.16. Since draft-tus-httpbis-resumable-uploads-protocol-00 . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Appendix B. Draft Version Identification . . . . . . . . . . . . 45
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
HTTP data transfers can encounter interruption due to reasons such as HTTP data transfers can encounter interruption due to reasons such as
canceled requests or dropped connections. If the intended recipient canceled requests or dropped connections. If the intended recipient
can indicate how much of the data was processed prior to can indicate how much of the data was processed prior to
interruption, a sender can resume data transfer at that point instead interruption, a sender can resume data transfer at that point instead
of attempting to transfer all of the data again. HTTP range requests of attempting to transfer all of the data again. HTTP range requests
(see Section 14 of [HTTP]) support this concept of resumable data (see Section 14 of [HTTP]) support this concept of resumable data
transfers for downloads from server to client. While partial PUT is transfers for downloads from server to client. While partial PUT is
skipping to change at page 8, line 50 skipping to change at page 8, line 50
| | | |
| 201 Created | | 201 Created |
| Location: /uploads/abc | | Location: /uploads/abc |
|<------------------------------------------------| |<------------------------------------------------|
| | | |
Figure 5: Upload creation with partial representation data Figure 5: Upload creation with partial representation data
2) Next, intermediate parts are appended (Section 4.4) with the 2) Next, intermediate parts are appended (Section 4.4) with the
"Upload-Complete" field value set to false, indicating that they are "Upload-Complete" field value set to false, indicating that they are
not the last part of the representation data. The offset value in not the last part of the representation data.
the "Upload-Offset" header field is taken from the previous response
when creating the upload or appending to it.
Client Server Client Server
| | | |
| PATCH /uploads/abc | | PATCH /uploads/abc |
| Upload-Complete: ?0 | | Upload-Complete: ?0 |
| Upload-Offset: X | | Upload-Offset: X |
| Content-Type: application/partial-upload | | Content-Type: application/partial-upload |
| | | |
| [partial representation from offset X] | | [partial representation from offset X] |
|------------------------------------------------>| |------------------------------------------------>|
skipping to change at page 11, line 17 skipping to change at page 11, line 17
4.1. State 4.1. State
The state of an upload consists of the following properties that are The state of an upload consists of the following properties that are
tracked by the server. tracked by the server.
4.1.1. Offset 4.1.1. Offset
The offset is the number of bytes from the representation data that The offset is the number of bytes from the representation data that
have been processed, either during the creation of the upload have been processed, either during the creation of the upload
resource (Section 4.2) or by appending to it (Section 4.4). The 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 offset is required when appending representation data (Section 4.4)
required when appending representation data (Section 4.4) to to synchronize the client and resource regarding the amount of
synchronize the client and resource regarding the amount of
transferred representation data. transferred representation data.
The offset reflects application-level processing for the upload. The offset reflects application-level processing for the upload.
Data may have been delivered and acknowledged at the transport layer Data may have been delivered and acknowledged at the transport layer
without yet being reflected in the offset. 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 The "Upload-Offset" request and response header field conveys the
offset. "Upload-Offset" is an Item Structured Header Field offset. "Upload-Offset" is an Item Structured Header Field
([STRUCTURED-FIELDS]). Its value is a non-negative Integer ([STRUCTURED-FIELDS]). Its value is a non-negative Integer
(Section 3.3.1 of [STRUCTURED-FIELDS]) and indicates the current (Section 3.3.1 of [STRUCTURED-FIELDS]) and indicates the current
offset as viewed by the message sender. Other values MUST cause the offset as viewed by the message sender. Other values MUST cause the
entire header field to be ignored. entire header field to be ignored.
The "Upload-Offset" header field in responses serves as an The client obtains the current offset in multiple ways:
acknowledgment of the processed representation data and as a
guarantee that no retransmission of it will be necessary. Clients o The offset can be explicitly retrieved from the upload resource
can use this guarantee to free resources associated to transferred (Section 4.3).
representation data.
o Interim and final responses for creating the upload (Section 4.2)
or appending (Section 4.4) with a non-"2XX" status code and the
"Upload-Complete: ?0" header can include the "Upload-Offset"
header field.
o Final responses for appending representation data (Section 4.4)
with a "2XX" status code and the "Upload-Complete: ?0" header
acknowledge that the entire request content was received and the
offset increased by the length of the appended representation
data. An "Upload-Offset" header field's value MUST match this
inferred offset, if present.
Representation data processed by the upload resource cannot be
removed again and, therefore, the offset as seen by the client MUST
NOT decrease. Clients can use this guarantee to free resources
associated to transferred representation data, as no retransmission
of it will be necessary. If the server loses any part of the state,
it MUST deactivate the upload resource and reject further interaction
with it.
4.1.2. Completeness 4.1.2. Completeness
An upload is incomplete until it is explicitly marked as completed by An upload is incomplete until it is explicitly marked as completed by
the client or the server. After this point, no more representation the client or the server. After this point, no more representation
data can be appended. data can be appended.
The "Upload-Complete" request and response header field conveys the The "Upload-Complete" request and response header field conveys the
completeness state. "Upload-Complete" is an Item Structured Header completeness state. "Upload-Complete" is an Item Structured Header
Field ([STRUCTURED-FIELDS]). Its value is a Boolean (Section 3.3.6 Field ([STRUCTURED-FIELDS]). Its value is a Boolean (Section 3.3.6
skipping to change at page 14, line 26 skipping to change at page 14, line 40
creation (Section 4.2) request. The server might reject requests creation (Section 4.2) request. The server might reject requests
below this limit. A client that is aware of this limit MUST NOT below this limit. A client that is aware of this limit MUST NOT
send smaller upload append or upload creation requests. The value send smaller upload append or upload creation requests. The value
is an Integer. This limit does not apply to upload creation is an Integer. This limit does not apply to upload creation
requests with no content, or to requests completing the upload by requests with no content, or to requests completing the upload by
including the "Upload-Complete: ?1" header field. including the "Upload-Complete: ?1" header field.
max-age: Specifies the remaining lifetime of the upload resource in max-age: Specifies the remaining lifetime of the upload resource in
seconds counted from the generation of the response. After the seconds counted from the generation of the response. After the
resource's lifetime is reached, the server might make the upload resource's lifetime is reached, the server might make the upload
resource inaccessible and a client SHOULD NOT attempt to access resource inaccessible. The value is an Integer.
the upload resource as these requests will likely fail. The value
is an Integer.
Clients usually discover limits through the "Upload-Limit" header Clients usually discover limits through the "Upload-Limit" header
field when the upload resource is created (Section 4.2). Throughout field when the upload resource is created (Section 4.2). Throughout
the lifetime of the upload resource, these limits SHOULD NOT change the lifetime of the upload resource, these limits SHOULD NOT change
in a way that causes failures for clients adhering to the initially in a way that causes failures for clients adhering to the initially
discovered limits. If the client discovers that it cannot continue discovered limits. If the client discovers that it cannot continue
the upload while adhering to the limits, it SHOULD stop the current the upload while adhering to the limits, it SHOULD stop the current
request immediately (Section 12) and cancel the upload (Section 4.5). request immediately (Section 12) and cancel the upload (Section 4.5).
The following recommendations for limit changes can minimize the risk The following recommendations for limit changes can minimize the risk
skipping to change at page 17, line 28 skipping to change at page 17, line 39
If the client received a final response with the "Upload-Complete: If the client received a final response with the "Upload-Complete:
?1" header field, the upload is complete and the corresponding ?1" header field, the upload is complete and the corresponding
response comes from the resource processing the representation response comes from the resource processing the representation
according to the initial request (Section 4.1.2). Note that this according to the initial request (Section 4.1.2). Note that this
does not necessarily indicate success. "4xx (Client Error)" or "5xx does not necessarily indicate success. "4xx (Client Error)" or "5xx
(Server Error)" status codes indicate in this case an error occurred (Server Error)" status codes indicate in this case an error occurred
while processing the representation, and therefore, resuming the while processing the representation, and therefore, resuming the
upload would not resolve this error. upload would not resolve this error.
If the client receives a 2xx successful final response with the If the client receives a 2xx successful final response with the
"Upload-Complete" header field set to false or missing, the "Upload-Complete" header field set to false or missing, and the
client's "Upload-Complete" request header field was set to false, the
"Location" response header field points the client to the created "Location" response header field points the client to the created
upload resource. The client can continue appending representation upload resource. The client can continue appending representation
data to it (Section 4.4). data to it (Section 4.4).
If the client receives a 4xx client error or 5xx server error final If the client receives a 4xx client error or 5xx server error final
response with the "Upload-Complete" header field set to false or 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 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. heuristics described in Section 4.7 to retry or resume the upload.
4.2.2. Server Behavior 4.2.2. Server Behavior
skipping to change at page 18, line 15 skipping to change at page 18, line 29
The resource targeted by this initial request is responsible for The resource targeted by this initial request is responsible for
processing the representation data transferred in the resumable processing the representation data transferred in the resumable
upload according to the method and header fields in the initial upload according to the method and header fields in the initial
request. The upload resource, on the other hand, enables resuming request. The upload resource, on the other hand, enables resuming
the transfer. the transfer.
If the "Upload-Complete" request header field is set to true, the If the "Upload-Complete" request header field is set to true, the
client intends to transfer the entire representation data in one client intends to transfer the entire representation data in one
request. If the request content was fully processed, no resumable request. If the request content was fully processed, no resumable
upload is needed and the server proceeds to process the request and upload is needed and the server proceeds to process the request and
generate a response. generate a response. The server MUST NOT emit a 2xx successful
response with the "Upload-Complete" header field set to false or
missing in response to a request with the "Upload-Complete" request
header field set to true.
If the "Upload-Complete" request header field is set to false, the If the "Upload-Complete" request header field is set to false, the
client intends to transfer the representation over multiple requests. client intends to transfer the representation over multiple requests.
If the request content was fully processed, the server MUST include If the request content was fully processed, the server MUST include
the "Location" response header field pointing to the upload resource the "Location" response header field pointing to the upload resource
and MUST include the "Upload-Limit" header field with the and MUST include the "Upload-Limit" header field with the
corresponding limits if existing. Servers are RECOMMENDED to use the corresponding limits if existing. Servers are RECOMMENDED to use the
"201 (Created)" status code. "201 (Created)" status code.
The server MUST record the representation's length according to The server MUST record the representation's length according to
skipping to change at page 18, line 52 skipping to change at page 19, line 20
verify this. If verification fails, clients SHOULD abort the current verify this. If verification fails, clients SHOULD abort the current
request and cancel the upload (Section 4.5). request and cancel the upload (Section 4.5).
The server SHOULD include the "Upload-Complete" (Section 4.1.2) The server SHOULD include the "Upload-Complete" (Section 4.1.2)
header field in the response to indicate whether it is the result of header field in the response to indicate whether it is the result of
processing the uploaded representation. processing the uploaded representation.
The server SHOULD NOT generate a response with the "301 (Moved The server SHOULD NOT generate a response with the "301 (Moved
Permanently)", "302 (Found)", or "303 (See Other)" status codes and Permanently)", "302 (Found)", or "303 (See Other)" status codes and
the "Upload-Complete: ?0" header field because clients might follow the "Upload-Complete: ?0" header field because clients might follow
the redirect without preserving the original method. the redirect without preserving the original method. See
Section 13.1 for redirecting a response that completes the upload.
The server might not process the entire request content when the The server might not process the entire request content when the
upload is interrupted, for example because of dropped connection or upload is interrupted, for example because of dropped connection or
canceled request. In this case, the server SHOULD append as much of canceled request. In this case, the server SHOULD append as much of
the request content as possible to the upload resource, allowing the the request content as possible to the upload resource, allowing the
client to resume the upload from where it was interrupted. In client to resume the upload from where it was interrupted. In
addition, the upload resource MUST NOT be considered complete then. addition, the upload resource MUST NOT be considered complete then.
4.2.3. Examples 4.2.3. Examples
skipping to change at page 21, line 27 skipping to change at page 21, line 48
"GET" request to the upload resource. Using "HEAD" is RECOMMENDED, "GET" request to the upload resource. Using "HEAD" is RECOMMENDED,
since response content is not required for resumption. Upon a since response content is not required for resumption. Upon a
successful response, the client can continue the upload by appending successful response, the client can continue the upload by appending
representation data (Section 4.4) starting at the offset indicated by representation data (Section 4.4) starting at the offset indicated by
the "Upload-Offset" response header field. the "Upload-Offset" response header field.
The offset can be less than or equal to the number of bytes of 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 representation data that the client has already sent. The client is
expected to handle backtracking of a reasonable length. On the other expected to handle backtracking of a reasonable length. On the other
hand, the offset can be greater than the amount of sent hand, the offset can be greater than the amount of sent
representation data if the upload resource obtained additional representation data, for example, if the server obtained additional
representation data on behalf of the client. If the client is not representation data on behalf of the client. If the client is not
able to provide the representation data at the given offset, the able to provide the representation data at the given offset, the
upload MUST be considered a failure. The client then MUST NOT upload MUST be considered a failure. The client then MUST NOT
continue the upload and SHOULD cancel the upload (Section 4.5). continue the upload and SHOULD cancel the upload (Section 4.5).
The client MUST NOT perform offset retrieval while creation The client MUST NOT perform offset retrieval while the creation
(Section 4.2) or appending (Section 4.4) is in progress as this can (Section 4.2) of or appending (Section 4.4) to the same upload
cause the previous request to be terminated by the server as resource is in progress as this can cause the previous request to be
described in Section 4.6. terminated by the server as described in Section 4.6.
If the client receives a 2xx successful response, the client can If the client receives a 2xx successful response with a valid Upload-
continue appending representation data to it and/or mark the upload Offset header field, the client can continue appending representation
as complete (Section 4.4). data to it (Section 4.4).
If the client receives a 4xx client error or 5xx server error If the client receives a 2xx successful response without a valid
Upload-Offset header field, a 4xx client error, or 5xx server error
response, or if it did not receive a response, the client MAY retry response, or if it did not receive a response, the client MAY retry
retrieving the offset. retrieving the offset.
4.3.2. Server Behavior 4.3.2. Server Behavior
A successful response to a "HEAD" or "GET" request against an upload A successful response to a "HEAD" or "GET" request against an upload
resource resource
o MUST include the offset in the "Upload-Offset" header field o MUST include the offset in the "Upload-Offset" header field
(Section 4.1.1), (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 o MUST indicate the limits in the "Upload-Limit" header field
(Section 4.1.4), and (Section 4.1.4), and
o SHOULD include the "Cache-Control" header field with the value o SHOULD include the "Cache-Control" header field with the value
"no-store" to prevent HTTP caching ([CACHING]). "no-store" to prevent HTTP caching ([CACHING]).
The server SHOULD NOT generate a response with the "301 (Moved The server SHOULD NOT generate a response with the "301 (Moved
Permanently)", "302 (Found)", or "303 (See Other)" status codes Permanently)", "302 (Found)", or "303 (See Other)" status codes
because clients might follow the redirect without preserving the because clients might follow the redirect without preserving the
"HEAD" method. "HEAD" method.
skipping to change at page 23, line 4 skipping to change at page 23, line 16
Host: example.com Host: example.com
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Upload-Complete: ?0 Upload-Complete: ?0
Upload-Offset: 25000000 Upload-Offset: 25000000
Upload-Length: 100000000 Upload-Length: 100000000
Upload-Limit: max-age=3600 Upload-Limit: max-age=3600
Cache-Control: no-store Cache-Control: no-store
4.4. Upload Append 4.4. Upload Append
4.4.1. Client Behavior 4.4.1. Client Behavior
A client can continue the upload and append representation data by A client can continue the upload and append representation data by
sending a "PATCH" request with the "application/partial-upload" media sending a "PATCH" request with the "application/partial-upload" media
type (Section 6) to the upload resource. The request content is the type (Section 6) to the upload resource. The request content is the
representation data to append. The request can benefit from representation data to append. The request can benefit from
incremental delivery; see Section 11. incremental delivery; see Section 11.
The client MUST indicate the offset of the request content inside the The client MUST indicate the offset of the request content inside the
representation data by including the "Upload-Offset" header field. representation data by including the "Upload-Offset" header field.
To ensure that the upload resource will accept the request, the To ensure that the upload resource will accept the request, the
offset SHOULD be taken from an immediate previous response for offset SHOULD be taken from an immediate previous response for
retrieving the offset (Section 4.3) or appending representation data retrieving the offset (Section 4.3), creating the upload
(Section 4.4). (Section 4.2), or appending representation data (Section 4.4).
The request MUST include the "Upload-Complete" header field. Its The request MUST include the "Upload-Complete" header field. Its
value is true in two cases: value is true in two cases:
o the request has content that is the end of the representation o the request has content that is the end of the representation
data. Once the content is fully processed by the server, the data. Once the content is fully processed by the server, the
upload is complete. upload is complete.
o the request has no content. Once the request is processed by the o the request has no content. Once the request is processed by the
server, the upload is complete. This usage requires the full server, the upload is complete. This usage requires the full
skipping to change at page 23, line 43 skipping to change at page 24, line 9
according to the initial request (Section 4.1.2). Note that this according to the initial request (Section 4.1.2). Note that this
does not necessarily indicate success. "4xx (Client Error)" or "5xx does not necessarily indicate success. "4xx (Client Error)" or "5xx
(Server Error)" status codes indicate in this case an error occurred (Server Error)" status codes indicate in this case an error occurred
while processing the representation, and therefore, resuming the while processing the representation, and therefore, resuming the
upload would not resolve this error. upload would not resolve this error.
If the client received a 4xx client error or 5xx server error final If the client received a 4xx client error or 5xx server error final
response with the "Upload-Complete" header field set to false or 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 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. heuristics described in Section 4.7 to retry or resume the upload.
Otherwise, the upload is considered a failure.
4.4.2. Server Behavior 4.4.2. Server Behavior
A server applies a "PATCH" request with the "application/partial- A server applies a "PATCH" request with the "application/partial-
upload" media type (Section 6) to an upload resource by appending the upload" media type (Section 6) to an upload resource by appending the
patch document in the request content. patch document in the request content.
The server might not process the entire patch document when the The server might not process the entire patch document when the
upload is interrupted, for example because of a dropped connection or upload is interrupted, for example because of a dropped connection or
canceled request. In this case, the server SHOULD append as much of canceled request. In this case, the server SHOULD append as much of
skipping to change at page 24, line 31 skipping to change at page 24, line 46
If the "Upload-Complete" request header field is set to true, the If the "Upload-Complete" request header field is set to true, the
client intends to transfer the remaining representation data in one client intends to transfer the remaining representation data in one
request. If the request content was fully processed, the upload is request. If the request content was fully processed, the upload is
marked as complete and the server SHOULD generate the response that marked as complete and the server SHOULD generate the response that
matches what the resource, that was targeted by the initial upload matches what the resource, that was targeted by the initial upload
creation (Section 4.2), would have generated if it had processed the creation (Section 4.2), would have generated if it had processed the
entire representation in the initial request. However, the response entire representation in the initial request. However, the response
MUST include the "Upload-Complete" header field with a true value, MUST include the "Upload-Complete" header field with a true value,
allowing clients to identify whether a response, in particular error allowing clients to identify whether a response, in particular error
responses, is related to the resumable upload itself or the responses, is related to the resumable upload itself or the
processing of the uploaded representation. processing of the uploaded representation. The server MUST NOT emit
a 2xx successful response with the "Upload-Complete" header field set
to false or missing in response to a request with the "Upload-
Complete" request header field set to true.
If the "Upload-Complete" request header field is set to false, the If the "Upload-Complete" request header field is set to false, the
client intends to transfer the remaining representation data over client intends to transfer the remaining representation data over
multiple requests. If the request content was fully processed, the multiple requests. If the request content was fully processed, the
server acknowledges the appended data by sending a "2xx (Successful)" server acknowledges the appended data by sending a "2xx (Successful)"
response with the "Upload-Complete" header field set to false. response with the "Upload-Complete" header field set to false.
Even if the upload is complete (Section 4.1.2) in the server's Even if the upload is complete (Section 4.1.2) in the server's
perspective and the final response from the targeted resource has perspective and the final response from the targeted resource has
already been sent, the client might still perform an upload append already been sent, the client might still perform an upload append
skipping to change at page 25, line 22 skipping to change at page 25, line 39
to inform the client about the upload progress. These interim to inform the client about the upload progress. These interim
responses MUST NOT include the "Location" header field. responses MUST NOT include the "Location" header field.
The server SHOULD include the "Upload-Complete" (Section 4.1.2) The server SHOULD include the "Upload-Complete" (Section 4.1.2)
header field in the response to indicate whether it is the result of header field in the response to indicate whether it is the result of
processing the uploaded representation. processing the uploaded representation.
The server SHOULD NOT generate a response with the "301 (Moved The server SHOULD NOT generate a response with the "301 (Moved
Permanently)", "302 (Found)", or "303 (See Other)" status codes and Permanently)", "302 (Found)", or "303 (See Other)" status codes and
the "Upload-Complete: ?0" header field because clients might follow the "Upload-Complete: ?0" header field because clients might follow
the redirect without preserving the "PATCH" method. the redirect without preserving the "PATCH" method. See Section 13.1
for redirecting a response that completes the upload.
4.4.3. Examples 4.4.3. Examples
A) The following example shows an upload append request. The client A) The following example shows an upload append request. The client
transfers the next 3456789 bytes at an offset of 20000000 and does transfers the next 3456789 bytes at an offset of 20000000 and does
not indicate that the upload is then completed. The server generates not indicate that the upload is then completed. The server generates
one interim response, when the offset reached 21728394 bytes, and one interim response, when the offset reached 21728394 bytes, and
finally acknowledges the new offset: finally acknowledges the new offset:
PATCH /upload/37a504d87 HTTP/1.1 PATCH /upload/37a504d87 HTTP/1.1
skipping to change at page 27, line 13 skipping to change at page 27, line 33
The following example shows an upload cancellation: The following example shows an upload cancellation:
DELETE /upload/5688a431c HTTP/1.1 DELETE /upload/5688a431c HTTP/1.1
Host: example.com Host: example.com
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
4.6. Concurrency 4.6. Concurrency
Resumable uploads, as defined in this document, do not permit Resumable uploads, as defined in this document, do not permit
uploading representation data in parallel to the same upload uploading representation data in parallel requests for the same
resource. The client MUST NOT perform multiple representation data upload. The client MUST NOT perform multiple representation data
transfers for the same upload resource in parallel. transfers for the same upload resource in parallel, or perform
representation data transfers while the creation of the same upload
resource is still in progress.
Even if the client is well-behaved and doesn't send concurrent Even if the client is well-behaved and doesn't send concurrent
requests, network interruptions can occur in such a way that the requests, network interruptions can occur in such a way that the
client considers a request as failed while the server is unaware of client considers a request as failed while the server is unaware of
the problem and considers the request still ongoing. The client the problem and considers the request still ongoing. The client
might then try to resume the upload with the best intentions, might then try to resume the upload with the best intentions,
resulting in concurrent requests from the server's perspective. resulting in concurrent requests from the server's perspective.
Therefore, the server MUST take measures to prevent race conditions, Therefore, the server MUST take measures to prevent race conditions,
data loss and corruption from concurrent requests to append data loss and corruption from concurrent requests to append
representation data (Section 4.4) and/or cancellation (Section 4.5) representation data (Section 4.4) and/or cancellation (Section 4.5)
to the same upload resource. In addition, the server MUST NOT send to the same upload resource. In addition, the server MUST NOT send
outdated information in responses when retrieving the offset outdated information in responses. This means that the offset
(Section 4.3). This means that the offset sent by the server MUST be communicated through final responses as defined in Section 4.1.1 MUST
accepted in a subsequent request to append representation data if no be accepted in a subsequent request to append representation data if
other request to append representation data or cancel was received in no other request to append representation data or cancel was received
the meantime. In other words, clients have to be able to use in the meantime. In other words, clients have to be able to use
received offsets. received offsets.
The RECOMMENDED approach is as follows: If a server receives a new The RECOMMENDED approach is as follows: If a server receives a new
request to retrieve the offset (Section 4.3), append representation request to retrieve the offset (Section 4.3), append representation
data (Section 4.4), or cancel the upload (Section 4.5) while a data (Section 4.4), or cancel the upload (Section 4.5) while a
previous request for creating the upload (Section 4.2) or appending previous request for creating the upload (Section 4.2) or appending
representation data (Section 4.4) to the same upload resource is representation data (Section 4.4) to the same upload resource is
still ongoing, the server SHOULD prevent race conditions, data loss, still ongoing, the server SHOULD prevent race conditions, data loss,
and corruption by terminating the previous request before processing and corruption by terminating the previous request before processing
the new request. Due to network delay and reordering, the server the new request. Due to network delay and reordering, the server
skipping to change at page 35, line 35 skipping to change at page 36, line 19
upload resource can exist. upload resource can exist.
Uploads performed as a series of appends can be used to upload data 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 up to the "max-size" limit, which could be a larger size than a
server or intermediary might normally permit in conventional single server or intermediary might normally permit in conventional single
upload request message content. Servers or intermediaries need to upload request message content. Servers or intermediaries need to
consider that relying solely on message content limits to constrain consider that relying solely on message content limits to constrain
resources allocated to uploads might not be an effective strategy resources allocated to uploads might not be an effective strategy
when using resumable uploads. when using resumable uploads.
13.1. Different Origins
The resource targeted by the initial request (Section 4.2) and the
upload resource might have different origins ([ORIGIN]). For
example, the initial request might be sent to an application server,
while the upload resource is hosted by a dedicated storage service.
Clients have to consider this change of origin when following the
"Location" header field to the upload resource. Credentials and
other per-origin state associated with the initially targeted
resource are not necessarily applicable to the upload resource, and
remain scoped to their respective origins. Clients also have to
consider that disclosing an upload resource URI to a different origin
can leak the capability to read, append to, or cancel the upload.
Because the upload can be completed either by the initial request or
by an upload append request (Section 4.4), the final response might
come from a different origin depending on whether the upload was
resumed. To avoid this, the server MAY respond to the request that
completes the upload with a "303 (See Other)" status code,
redirecting the user agent to the origin of the initially targeted
resource. Because a "303 (See Other)" response directs the user
agent to retrieve the result with "GET", the considerations regarding
method preservation in Section 4.2 and Section 4.4 do not apply in
this case.
14. IANA Considerations 14. IANA Considerations
14.1. HTTP Fields 14.1. HTTP Fields
IANA is asked to register the following entries in the "Hypertext IANA is asked to register the following entries in the "Hypertext
Transfer Protocol (HTTP) Field Name Registry": Transfer Protocol (HTTP) Field Name Registry":
+-----------------+-----------+-------------+-----------------------+ +-----------------+-----------+-------------+-----------------------+
| Field Name | Status | Structured | Reference | | Field Name | Status | Structured | Reference |
| | | Type | | | | | Type | |
skipping to change at page 39, line 26 skipping to change at page 40, line 26
[STRUCTURED-FIELDS] [STRUCTURED-FIELDS]
Nottingham, M. and P. Kamp, "Structured Field Values for Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/info/rfc9651>. <https://www.rfc-editor.org/info/rfc9651>.
15.2. Informative References 15.2. Informative References
[INCREMENTAL] [INCREMENTAL]
Oku, K., Pauly, T., and M. Thomson, "Incremental Oku, K., Pauly, T., and M. Thomson, "Incremental
Forwarding of HTTP Messages", draft-ietf-httpbis- Forwarding of HTTP Messages", RFC 10036,
incremental-04 (work in progress), March 2026. DOI 10.17487/RFC10036, August 2026,
<https://www.rfc-editor.org/info/rfc10036>.
[ORIGIN] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and "Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>. <https://www.rfc-editor.org/info/rfc8792>.
[SLOWLORIS] [SLOWLORIS]
"RSnake" Hansen, R., "Welcome to Slowloris - the low "RSnake" Hansen, R., "Welcome to Slowloris - the low
bandwidth, yet greedy and poisonous HTTP client!", June bandwidth, yet greedy and poisonous HTTP client!", June
2009, <https://web.archive.org/web/20150315054838/ 2009, <https://web.archive.org/web/20150315054838/
http://ha.ckers.org/slowloris/>. http://ha.ckers.org/slowloris/>.
15.3. URIs 15.3. URIs
[1] https://tus.io/ [1] https://tus.io/
Appendix A. Changes Appendix A. Changes
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
A.1. Since draft-ietf-httpbis-resumable-upload-11 A.1. Since draft-ietf-httpbis-resumable-upload-12
o Upload-Complete and Upload-Length are no longer required on offset
retrieval responses.
o Remove discouragement against sending requests after expiration.
o Clarify how upload offset is inferred from responses.
o Disallow successful responses indicating an incomplete upload when
the request indicated completion.
o Describe considerations for the initially targeted resource and
the upload resource having different origins.
A.2. Since draft-ietf-httpbis-resumable-upload-11
o Clear up different responsibilities of server and upload resource. o Clear up different responsibilities of server and upload resource.
o Relax recommendations on client handling greater offsets. o Relax recommendations on client handling greater offsets.
o Clarify client behavior for 413 responses. o Clarify client behavior for 413 responses.
o Remove Accept-Patch from OPTIONS responses. o Remove Accept-Patch from OPTIONS responses.
o Allow upload creation requests with no content regardless of the o Allow upload creation requests with no content regardless of the
skipping to change at page 40, line 39 skipping to change at page 42, line 15
o Clarify that clients might not know limits when starting upload. o Clarify that clients might not know limits when starting upload.
o Remove section covering integrity digests. o Remove section covering integrity digests.
o Increase the draft interop version. o Increase the draft interop version.
o Add version-specific details on cancelling in-flight transfers. o Add version-specific details on cancelling in-flight transfers.
o Clarify client retry strategies. o Clarify client retry strategies.
A.2. Since draft-ietf-httpbis-resumable-upload-10 A.3. Since draft-ietf-httpbis-resumable-upload-10
o Add recommended disposition type for file name indication. o Add recommended disposition type for file name indication.
A.3. Since draft-ietf-httpbis-resumable-upload-09 A.4. Since draft-ietf-httpbis-resumable-upload-09
o Requires Accept-Patch in OPTIONS. o Requires Accept-Patch in OPTIONS.
o Add security consideration regarding time-of-check to time-of-use. o Add security consideration regarding time-of-check to time-of-use.
o Lift requirement on Upload-Complete for all final responses. o Lift requirement on Upload-Complete for all final responses.
o Relax requirements on limit changes. o Relax requirements on limit changes.
o Describe the interaction between 100 and 104 responses. o Describe the interaction between 100 and 104 responses.
o Numerous editorial improvements. o Numerous editorial improvements.
A.4. Since draft-ietf-httpbis-resumable-upload-08 A.5. Since draft-ietf-httpbis-resumable-upload-08
o Clarify definitions of new header fields. o Clarify definitions of new header fields.
o Make handling of OPTIONS * optional. o Make handling of OPTIONS * optional.
o Require server to announce limits using Upload-Limit. o Require server to announce limits using Upload-Limit.
o Require clients to adhere to known limits. o Require clients to adhere to known limits.
o Rephrase requirements for concurrency handling, focusing on the o Rephrase requirements for concurrency handling, focusing on the
outcome. outcome.
o Remove requirement for 204 status code for DELETE responses. o Remove requirement for 204 status code for DELETE responses.
o Increase the draft interop version. o Increase the draft interop version.
o Add section about 104 status code. o Add section about 104 status code.
o Rephrase recommendation for sending information back to client. o Rephrase recommendation for sending information back to client.
A.5. Since draft-ietf-httpbis-resumable-upload-07 A.6. Since draft-ietf-httpbis-resumable-upload-07
o Clarify server handling when upload length is exceeded. o Clarify server handling when upload length is exceeded.
o Extend security considerations about upload resource URIs, o Extend security considerations about upload resource URIs,
representation metadata, and untrusted inputs. representation metadata, and untrusted inputs.
o Allow clients to retry for appropriate 4xx responses. o Allow clients to retry for appropriate 4xx responses.
A.6. Since draft-ietf-httpbis-resumable-upload-06 A.7. Since draft-ietf-httpbis-resumable-upload-06
o Minor editorial improvements to introduction and examples. o Minor editorial improvements to introduction and examples.
o Define structured types for new header fields. o Define structured types for new header fields.
A.7. Since draft-ietf-httpbis-resumable-upload-05 A.8. Since draft-ietf-httpbis-resumable-upload-05
o Increase the draft interop version. o Increase the draft interop version.
o Numerous editorial changes. o Numerous editorial changes.
o Rename "expires" limit to "max-age". o Rename "expires" limit to "max-age".
o Require "Upload-Complete", but not "Upload-Offset" or "Upload- o Require "Upload-Complete", but not "Upload-Offset" or "Upload-
Limit", for append responses. Limit", for append responses.
o Add problem type for inconsistent length values. o Add problem type for inconsistent length values.
o Reduce use of "file" in favor of "representation". o Reduce use of "file" in favor of "representation".
A.8. Since draft-ietf-httpbis-resumable-upload-04 A.9. Since draft-ietf-httpbis-resumable-upload-04
o Clarify implications of "Upload-Limit" header. o Clarify implications of "Upload-Limit" header.
o Allow client to fetch upload limits upfront via "OPTIONS". o Allow client to fetch upload limits upfront via "OPTIONS".
o Add guidance on upload creation strategy. o Add guidance on upload creation strategy.
o Add "Upload-Length" header to indicate length during creation. o Add "Upload-Length" header to indicate length during creation.
o Describe possible usage of "Want-Repr-Digest". o Describe possible usage of "Want-Repr-Digest".
A.9. Since draft-ietf-httpbis-resumable-upload-03 A.10. Since draft-ietf-httpbis-resumable-upload-03
o Add note about "Content-Location" for referring to subsequent o Add note about "Content-Location" for referring to subsequent
resources. resources.
o Require "application/partial-upload" for appending to uploads. o Require "application/partial-upload" for appending to uploads.
o Explain handling of content and transfer codings. o Explain handling of content and transfer codings.
o Add problem types for mismatching offsets and completed uploads. o Add problem types for mismatching offsets and completed uploads.
o Clarify that completed uploads must not be appended to. o Clarify that completed uploads must not be appended to.
o Describe interaction with Digest Fields from RFC9530. o Describe interaction with Digest Fields from RFC9530.
o Require that upload offset does not decrease over time. o Require that upload offset does not decrease over time.
o Add Upload-Limit header field. o Add Upload-Limit header field.
o Increase the draft interop version. o Increase the draft interop version.
A.10. Since draft-ietf-httpbis-resumable-upload-02 A.11. Since draft-ietf-httpbis-resumable-upload-02
o Add upload progress notifications via informational responses. o Add upload progress notifications via informational responses.
o Add security consideration regarding request filtering. o Add security consideration regarding request filtering.
o Explain the use of empty requests for creation uploads and o Explain the use of empty requests for creation uploads and
appending. appending.
o Extend security consideration to include resource exhaustion o Extend security consideration to include resource exhaustion
attacks. attacks.
o Allow 200 status codes for offset retrieval. o Allow 200 status codes for offset retrieval.
o Increase the draft interop version. o Increase the draft interop version.
A.11. Since draft-ietf-httpbis-resumable-upload-01 A.12. Since draft-ietf-httpbis-resumable-upload-01
o Replace Upload-Incomplete header with Upload-Complete. o Replace Upload-Incomplete header with Upload-Complete.
o Replace terminology about procedures with HTTP resources. o Replace terminology about procedures with HTTP resources.
o Increase the draft interop version. o Increase the draft interop version.
A.12. Since draft-ietf-httpbis-resumable-upload-00 A.13. Since draft-ietf-httpbis-resumable-upload-00
o Remove Upload-Token and instead use Server-generated upload URL o Remove Upload-Token and instead use Server-generated upload URL
for upload identification. for upload identification.
o Require the Upload-Incomplete header field in Upload Creation o Require the Upload-Incomplete header field in Upload Creation
Procedure. Procedure.
o Increase the draft interop version. o Increase the draft interop version.
A.13. Since draft-tus-httpbis-resumable-uploads-protocol-02 A.14. Since draft-tus-httpbis-resumable-uploads-protocol-02
None None
A.14. Since draft-tus-httpbis-resumable-uploads-protocol-01 A.15. Since draft-tus-httpbis-resumable-uploads-protocol-01
o Clarifying backtracking and preventing skipping ahead during the o Clarifying backtracking and preventing skipping ahead during the
Offset Receiving Procedure. Offset Receiving Procedure.
o Clients auto-retry 404 is no longer allowed. o Clients auto-retry 404 is no longer allowed.
A.15. Since draft-tus-httpbis-resumable-uploads-protocol-00 A.16. Since draft-tus-httpbis-resumable-uploads-protocol-00
o Split the Upload Transfer Procedure into the Upload Creation o Split the Upload Transfer Procedure into the Upload Creation
Procedure and the Upload Appending Procedure. Procedure and the Upload Appending Procedure.
Appendix B. Draft Version Identification Appendix B. Draft Version Identification
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
To assist the development of implementations and interoperability To assist the development of implementations and interoperability
testing while this document is still a draft, an interop version is testing while this document is still a draft, an interop version is
defined. Implementations of this draft use the interop version to defined. Implementations of this draft use the interop version to
identify the iteration of the draft that they implement. The interop identify the iteration of the draft that they implement. The interop
version is bumped for breaking changes. version is bumped for breaking changes.
The current interop version is 9. The current interop version is 10.
Client implementations of draft versions of the protocol MUST send a Client implementations of draft versions of the protocol MUST send a
header field "Upload-Draft-Interop-Version" with the interop version header field "Upload-Draft-Interop-Version" with the interop version
as its value to its requests. The "Upload-Draft-Interop-Version" as its value to its requests. The "Upload-Draft-Interop-Version"
field value is an Integer. field value is an Integer.
Server implementations of draft versions of the protocol MUST NOT Server implementations of draft versions of the protocol MUST NOT
send a "104 (Upload Resumption Supported)" interim response when the send a "104 (Upload Resumption Supported)" interim response when the
interop version indicated by the "Upload-Draft-Interop-Version" interop version indicated by the "Upload-Draft-Interop-Version"
header field in the request is missing or mismatching. header field in the request is missing or mismatching.
skipping to change at page 45, line 4 skipping to change at page 46, line 28
protocol. Members of the tus community helped significantly in the protocol. Members of the tus community helped significantly in the
process of bringing this work to the IETF. process of bringing this work to the IETF.
The authors would like to thank Mark Nottingham for substantive The authors would like to thank Mark Nottingham for substantive
contributions to the text, along with the following in alphabetical contributions to the text, along with the following in alphabetical
order for their thorough reviews of the document: order for their thorough reviews of the document:
o Daniel Resnick o Daniel Resnick
o Glenn Strauss o Glenn Strauss
o Grant Gryczan o Grant Gryczan
o Julian Reschke o Julian Reschke
o Mert Alev o Mert Alev
o Mike Bishop o Mike Bishop
o Roy T. Fielding o Roy T. Fielding
o Willy Tarreau o Willy Tarreau
Authors' Addresses Authors' Addresses
Marius Kleidl (editor) Marius Kleidl (editor)
Transloadit Transloadit
Email: marius@transloadit.com Email: ietf@mariuskleidl.net
Guoye Zhang (editor) Guoye Zhang (editor)
Apple Inc. Apple Inc.
Email: guoye_zhang@apple.com Email: guoye_zhang@apple.com
Lucas Pardue (editor) Lucas Pardue (editor)
Cloudflare Cloudflare
Email: lucas@lucaspardue.com Email: lucas@lucaspardue.com
 End of changes. 55 change blocks. 
121 lines changed or deleted 185 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/