draft-ietf-httpbis-resumable-upload-04.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 9, 2025 Apple Inc. Expires: March 18, 2025 Apple Inc.
L. Pardue, Ed. L. Pardue, Ed.
Cloudflare Cloudflare
July 08, 2024 September 14, 2024
Resumable Uploads for HTTP Resumable Uploads for HTTP
draft-ietf-httpbis-resumable-upload-04 draft-ietf-httpbis-resumable-upload-latest
Abstract Abstract
HTTP clients often encounter interrupted data transfers as a result HTTP clients often encounter interrupted data transfers as a result
of canceled requests or dropped connections. Prior to interruption, of canceled requests or dropped connections. Prior to interruption,
part of a representation may have been exchanged. To complete the part of a representation may have been exchanged. To complete the
data transfer of the entire representation, it is often desirable to data transfer of the entire representation, it is often desirable to
issue subsequent requests that transfer only the remainder of the issue subsequent requests that transfer only the remainder of the
representation. HTTP range requests support this concept of representation. HTTP range requests support this concept of
resumable downloads from server to client. This document describes a resumable downloads from server to client. This document describes a
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 9, 2025. This Internet-Draft will expire on March 18, 2025.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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 3, line 13 skipping to change at page 3, line 13
12. Redirection . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Redirection . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Transfer and Content Codings . . . . . . . . . . . . . . . . 20 13. Transfer and Content Codings . . . . . . . . . . . . . . . . 20
14. Integrity Digests . . . . . . . . . . . . . . . . . . . . . . 20 14. Integrity Digests . . . . . . . . . . . . . . . . . . . . . . 20
15. Subsequent Resources . . . . . . . . . . . . . . . . . . . . 21 15. Subsequent Resources . . . . . . . . . . . . . . . . . . . . 21
16. Security Considerations . . . . . . . . . . . . . . . . . . . 21 16. Security Considerations . . . . . . . . . . . . . . . . . . . 21
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
18.1. Normative References . . . . . . . . . . . . . . . . . . 24 18.1. Normative References . . . . . . . . . . . . . . . . . . 24
18.2. Informative References . . . . . . . . . . . . . . . . . 25 18.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Informational Response . . . . . . . . . . . . . . . 25 Appendix A. Informational Response . . . . . . . . . . . . . . . 25
Appendix B. Feature Detection . . . . . . . . . . . . . . . . . 25 Appendix B. Feature Detection . . . . . . . . . . . . . . . . . 26
Appendix C. Upload Metadata . . . . . . . . . . . . . . . . . . 27 Appendix C. Upload Metadata . . . . . . . . . . . . . . . . . . 28
Appendix D. FAQ . . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix D. FAQ . . . . . . . . . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
F.1. Since draft-ietf-httpbis-resumable-upload-03 . . . . . . 28 F.1. Since draft-ietf-httpbis-resumable-upload-04 . . . . . . 29
F.2. Since draft-ietf-httpbis-resumable-upload-02 . . . . . . 29 F.2. Since draft-ietf-httpbis-resumable-upload-03 . . . . . . 29
F.3. Since draft-ietf-httpbis-resumable-upload-01 . . . . . . 29 F.3. Since draft-ietf-httpbis-resumable-upload-02 . . . . . . 29
F.4. Since draft-ietf-httpbis-resumable-upload-00 . . . . . . 29 F.4. Since draft-ietf-httpbis-resumable-upload-01 . . . . . . 29
F.5. Since draft-tus-httpbis-resumable-uploads-protocol-02 . . 29 F.5. Since draft-ietf-httpbis-resumable-upload-00 . . . . . . 30
F.6. Since draft-tus-httpbis-resumable-uploads-protocol-01 . . 30 F.6. Since draft-tus-httpbis-resumable-uploads-protocol-02 . . 30
F.7. Since draft-tus-httpbis-resumable-uploads-protocol-00 . . 30 F.7. Since draft-tus-httpbis-resumable-uploads-protocol-01 . . 30
F.8. Since draft-tus-httpbis-resumable-uploads-protocol-00 . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
HTTP clients often encounter interrupted data transfers as a result HTTP clients often encounter interrupted data transfers as a result
of canceled requests or dropped connections. Prior to interruption, of canceled requests or dropped connections. Prior to interruption,
part of a representation (see Section 3.2 of [HTTP]) might have been part of a representation (see Section 3.2 of [HTTP]) might have been
exchanged. To complete the data transfer of the entire exchanged. To complete the data transfer of the entire
representation, it is often desirable to issue subsequent requests representation, it is often desirable to issue subsequent requests
that transfer only the remainder of the representation. HTTP range that transfer only the remainder of the representation. HTTP range
skipping to change at page 13, line 5 skipping to change at page 13, line 5
data from an ongoing transfer for the same upload resource, which in data from an ongoing transfer for the same upload resource, which in
the client's perspective has failed. The server MAY terminate any the client's perspective has failed. The server MAY terminate any
transfers for the same upload resource before sending the response by transfers for the same upload resource before sending the response by
abruptly terminating the HTTP connection or stream. Alternatively, abruptly terminating the HTTP connection or stream. Alternatively,
the server MAY keep the ongoing transfer alive but ignore further the server MAY keep the ongoing transfer alive but ignore further
bytes received past the offset. bytes received past the offset.
The client MUST NOT start more than one append (Section 6) based on The client MUST NOT start more than one append (Section 6) based on
the resumption offset from a single offset retrieving request. the resumption offset from a single offset retrieving request.
In order to prevent HTTP caching, the response SHOULD include a In order to prevent HTTP caching ([CACHING]), the response SHOULD
"Cache-Control" header field with the value "no-store". include a "Cache-Control" header field with the value "no-store".
If the server does not consider the upload resource to be active, it If the server does not consider the upload resource to be active, it
MUST respond with a "404 (Not Found)" status code. MUST respond with a "404 (Not Found)" status code.
The resumption offset can be less than or equal to the number of The resumption offset can be less than or equal to the number of
bytes the client has already sent. The client MAY reject an offset bytes the client has already sent. The client MAY reject an offset
which is greater than the number of bytes it has already sent during which is greater than the number of bytes it has already sent during
this upload. The client is expected to handle backtracking of a this upload. The client is expected to handle backtracking of a
reasonable length. If the offset is invalid for this upload, or if reasonable length. If the offset is invalid for this upload, or if
the client cannot backtrack to the offset and reproduce the same the client cannot backtrack to the offset and reproduce the same
skipping to change at page 20, line 11 skipping to change at page 20, line 11
guarantee that no retransmission of the data will be necessary. guarantee that no retransmission of the data will be necessary.
Client can use this guarantee to free resources associated to already Client can use this guarantee to free resources associated to already
uploaded data while the upload is still ongoing. uploaded data while the upload is still ongoing.
12. Redirection 12. Redirection
The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT
be used in offset retrieval (Section 5) and upload cancellation be used in offset retrieval (Section 5) and upload cancellation
(Section 7) responses. For other responses, the upload resource MAY (Section 7) responses. For other responses, the upload resource MAY
return a "308 (Permanent Redirect)" status code and clients SHOULD return a "308 (Permanent Redirect)" status code and clients SHOULD
use new permanent URI for subsequent requests. If the client use the new permanent URI for subsequent requests. If the client
receives a "307 (Temporary Redirect)" response to an offset retrieval receives a "307 (Temporary Redirect)" response to an offset retrieval
(Section 5) request, it MAY apply the redirection directly in an (Section 5) request, it MAY apply the redirection directly in an
immediate subsequent upload append (Section 6). immediate subsequent upload append (Section 6).
13. Transfer and Content Codings 13. Transfer and Content Codings
A message might have a content coding, indicated by the "Content- A message might have a content coding, indicated by the "Content-
Encoding" header field, and/or a transfer coding, indicated by the Encoding" header field, and/or a transfer coding, indicated by the
"Transfer-Encoding" header field (Section 6.1 of [RFC9112]), applied, "Transfer-Encoding" header field (Section 6.1 of [RFC9112]), applied,
which modify the representation of uploaded data in a message. For which modify the representation of uploaded data in a message. For
skipping to change at page 21, line 14 skipping to change at page 21, line 14
15. Subsequent Resources 15. Subsequent Resources
The server might process the uploaded data and make its results The server might process the uploaded data and make its results
available in another resource during or after the upload. This available in another resource during or after the upload. This
subsequent resource is different from the upload resource created by subsequent resource is different from the upload resource created by
the upload creation request (Section 4). The subsequent resource the upload creation request (Section 4). The subsequent resource
does not handle the upload process itself, but instead facilitates does not handle the upload process itself, but instead facilitates
further interaction with the uploaded data. The server MAY indicate further interaction with the uploaded data. The server MAY indicate
the location of this subsequent resource by including the "Content- the location of this subsequent resource by including the "Content-
Location" header field in informational or final responses generated Location" header field in the informational or final responses
while creating (Section 4), appending to (Section 6), or retrieving generated while creating (Section 4), appending to (Section 6), or
the offset (Section 5) of an upload. For example, a subsequent retrieving the offset (Section 5) of an upload. For example, a
resource could allow the client to fetch information extracted from subsequent resource could allow the client to fetch information
the uploaded data. extracted from the uploaded data.
16. Security Considerations 16. Security Considerations
The upload resource URL is the identifier used for modifying the The upload resource URL is the identifier used for modifying the
upload. Without further protection of this URL, an attacker may upload. Without further protection of this URL, an attacker may
obtain information about an upload, append data to it, or cancel it. obtain information about an upload, append data to it, or cancel it.
To prevent this, the server SHOULD ensure that only authorized To prevent this, the server SHOULD ensure that only authorized
clients can access the upload resource. In addition, the upload clients can access the upload resource. In addition, the upload
resource URL SHOULD be generated in such a way that makes it hard to resource URL SHOULD be generated in such a way that makes it hard to
be guessed by unauthorized clients. be guessed by unauthorized clients.
skipping to change at page 24, line 9 skipping to change at page 24, line 9
Upload Is Completed Recommended HTTP status code: Upload Is Completed Recommended HTTP status code:
400 Reference: 400 Reference:
This document This document
18. References 18. References
18.1. Normative References 18.1. Normative References
[CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[DIGEST-FIELDS] [DIGEST-FIELDS]
Polli, R. and L. Pardue, "Digest Fields", RFC 9530, Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024, DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/info/rfc9530>. <https://www.rfc-editor.org/info/rfc9530>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
skipping to change at page 28, line 38 skipping to change at page 29, line 5
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. contributions to the text.
Changes Changes
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
F.1. Since draft-ietf-httpbis-resumable-upload-03 F.1. Since draft-ietf-httpbis-resumable-upload-04
None yet
F.2. 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.
F.2. Since draft-ietf-httpbis-resumable-upload-02 F.3. 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.
F.3. Since draft-ietf-httpbis-resumable-upload-01 F.4. 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.
F.4. Since draft-ietf-httpbis-resumable-upload-00 F.5. 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.
F.5. Since draft-tus-httpbis-resumable-uploads-protocol-02 F.6. Since draft-tus-httpbis-resumable-uploads-protocol-02
None None
F.6. Since draft-tus-httpbis-resumable-uploads-protocol-01 F.7. 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.
F.7. Since draft-tus-httpbis-resumable-uploads-protocol-00 F.8. 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.
Authors' Addresses Authors' Addresses
Marius Kleidl (editor) Marius Kleidl (editor)
Transloadit Transloadit
Email: marius@transloadit.com Email: marius@transloadit.com
 End of changes. 17 change blocks. 
28 lines changed or deleted 38 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/