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: February 21, 2027 Apple Inc.
L. Pardue, Ed. L. Pardue, Ed.
Cloudflare Cloudflare
July 6, 2026 August 20, 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 February 21, 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 50 skipping to change at page 2, line 50
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 . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . 21
4.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 22 4.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 22
4.4. Upload Append . . . . . . . . . . . . . . . . . . . . . . 22 4.4. Upload Append . . . . . . . . . . . . . . . . . . . . . . 22
4.4.1. Client Behavior . . . . . . . . . . . . . . . . . . . 23 4.4.1. Client Behavior . . . . . . . . . . . . . . . . . . . 22
4.4.2. Server Behavior . . . . . . . . . . . . . . . . . . . 23 4.4.2. Server Behavior . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . . . 26
4.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 26 4.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 26
4.6. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 27 4.6. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 26
4.7. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.7. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5. Status Code 104 (Upload Resumption Supported) . . . . . . . . 28 5. Status Code 104 (Upload Resumption Supported) . . . . . . . . 28
6. Media Type application/partial-upload . . . . . . . . . . . . 29 6. Media Type application/partial-upload . . . . . . . . . . . . 29
7. Problem Types . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Problem Types . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Mismatching Offset . . . . . . . . . . . . . . . . . . . 29 7.1. Mismatching Offset . . . . . . . . . . . . . . . . . . . 29
7.2. Inconsistent Length . . . . . . . . . . . . . . . . . . . 30 7.2. Inconsistent Length . . . . . . . . . . . . . . . . . . . 30
8. Content Codings . . . . . . . . . . . . . . . . . . . . . . . 30 8. Content Codings . . . . . . . . . . . . . . . . . . . . . . . 30
9. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 31 9. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 31
10. Upload Strategies . . . . . . . . . . . . . . . . . . . . . . 31 10. Upload Strategies . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Optimistic Upload Creation . . . . . . . . . . . . . . . 31 10.1. Optimistic Upload Creation . . . . . . . . . . . . . . . 31
10.1.1. Upgrading To Resumable Uploads . . . . . . . . . . . 32 10.1.1. Upgrading To Resumable Uploads . . . . . . . . . . . 32
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 . . . . . . . 33
12. Request Cancellation . . . . . . . . . . . . . . . . . . . . 33 12. Request Cancellation . . . . . . . . . . . . . . . . . . . . 33
13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
14.1. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . 35 14.1. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . 35
14.2. HTTP Status Code . . . . . . . . . . . . . . . . . . . . 36 14.2. HTTP Status Code . . . . . . . . . . . . . . . . . . . . 36
14.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 36 14.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 36
14.4. HTTP Problem Types . . . . . . . . . . . . . . . . . . . 37 14.4. HTTP Problem Types . . . . . . . . . . . . . . . . . . . 37
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.1. Normative References . . . . . . . . . . . . . . . . . . 38 15.1. Normative References . . . . . . . . . . . . . . . . . . 37
15.2. Informative References . . . . . . . . . . . . . . . . . 39 15.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 39
A.1. Since draft-ietf-httpbis-resumable-upload-11 . . . . . . 39 A.1. Since draft-ietf-httpbis-resumable-upload-12 . . . . . . 39
A.2. Since draft-ietf-httpbis-resumable-upload-10 . . . . . . 40 A.2. Since draft-ietf-httpbis-resumable-upload-11 . . . . . . 39
A.3. Since draft-ietf-httpbis-resumable-upload-09 . . . . . . 40 A.3. Since draft-ietf-httpbis-resumable-upload-10 . . . . . . 40
A.4. Since draft-ietf-httpbis-resumable-upload-08 . . . . . . 41 A.4. Since draft-ietf-httpbis-resumable-upload-09 . . . . . . 40
A.5. Since draft-ietf-httpbis-resumable-upload-07 . . . . . . 41 A.5. Since draft-ietf-httpbis-resumable-upload-08 . . . . . . 41
A.6. Since draft-ietf-httpbis-resumable-upload-06 . . . . . . 41 A.6. Since draft-ietf-httpbis-resumable-upload-07 . . . . . . 41
A.7. Since draft-ietf-httpbis-resumable-upload-05 . . . . . . 41 A.7. Since draft-ietf-httpbis-resumable-upload-06 . . . . . . 41
A.8. Since draft-ietf-httpbis-resumable-upload-04 . . . . . . 42 A.8. Since draft-ietf-httpbis-resumable-upload-05 . . . . . . 41
A.9. Since draft-ietf-httpbis-resumable-upload-03 . . . . . . 42 A.9. Since draft-ietf-httpbis-resumable-upload-04 . . . . . . 42
A.10. Since draft-ietf-httpbis-resumable-upload-02 . . . . . . 42 A.10. Since draft-ietf-httpbis-resumable-upload-03 . . . . . . 42
A.11. Since draft-ietf-httpbis-resumable-upload-01 . . . . . . 43 A.11. Since draft-ietf-httpbis-resumable-upload-02 . . . . . . 42
A.12. Since draft-ietf-httpbis-resumable-upload-00 . . . . . . 43 A.12. Since draft-ietf-httpbis-resumable-upload-01 . . . . . . 43
A.13. Since draft-tus-httpbis-resumable-uploads-protocol-02 . . 43 A.13. Since draft-ietf-httpbis-resumable-upload-00 . . . . . . 43
A.14. Since draft-tus-httpbis-resumable-uploads-protocol-01 . . 43 A.14. Since draft-tus-httpbis-resumable-uploads-protocol-02 . . 43
A.15. Since draft-tus-httpbis-resumable-uploads-protocol-00 . . 43 A.15. Since draft-tus-httpbis-resumable-uploads-protocol-01 . . 43
A.16. Since draft-tus-httpbis-resumable-uploads-protocol-00 . . 43
Appendix B. Draft Version Identification . . . . . . . . . . . . 43 Appendix B. Draft Version Identification . . . . . . . . . . . . 43
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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
skipping to change at page 21, line 27 skipping to change at page 21, line 27
"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 27, line 13 skipping to change at page 26, line 50
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)
skipping to change at page 39, line 48 skipping to change at page 39, line 36
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.
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 40, line 32
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.
 End of changes. 30 change blocks. 
59 lines changed or deleted 60 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/