draft-ietf-httpbis-resumable-upload-02.txt   draft-ietf-httpbis-resumable-upload-latest.txt 
HTTP Working Group M. Kleidl, Ed. HTTP Working Group M. Kleidl, Ed.
Internet-Draft Transloadit Ltd Internet-Draft Transloadit
Intended status: Standards Track G. Zhang, Ed. Intended status: Standards Track G. Zhang, Ed.
Expires: April 21, 2024 Apple Inc. Expires: August 1, 2024 Apple Inc.
L. Pardue, Ed. L. Pardue, Ed.
Cloudflare Cloudflare
October 19, 2023 January 29, 2024
Resumable Uploads for HTTP Resumable Uploads for HTTP
draft-ietf-httpbis-resumable-upload-02 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 April 21, 2024. This Internet-Draft will expire on August 1, 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 46 skipping to change at page 2, line 46
4. Upload Creation . . . . . . . . . . . . . . . . . . . . . . . 7 4. Upload Creation . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Feature Detection . . . . . . . . . . . . . . . . . . . . 10 4.1. Feature Detection . . . . . . . . . . . . . . . . . . . . 10
4.2. Draft Version Identification . . . . . . . . . . . . . . 10 4.2. Draft Version Identification . . . . . . . . . . . . . . 10
5. Offset Retrieval . . . . . . . . . . . . . . . . . . . . . . 11 5. Offset Retrieval . . . . . . . . . . . . . . . . . . . . . . 11
6. Upload Append . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Upload Append . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Upload Cancellation . . . . . . . . . . . . . . . . . . . . . 14 7. Upload Cancellation . . . . . . . . . . . . . . . . . . . . . 14
8. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Upload-Offset . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Upload-Offset . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Upload-Complete . . . . . . . . . . . . . . . . . . . . . 15 8.2. Upload-Complete . . . . . . . . . . . . . . . . . . . . . 15
9. Redirection . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Redirection . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. Normative References . . . . . . . . . . . . . . . . . . . . 16 12. Normative References . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Informational Response . . . . . . . . . . . . . . . 17 Appendix A. Informational Response . . . . . . . . . . . . . . . 17
Appendix B. Feature Detection . . . . . . . . . . . . . . . . . 18 Appendix B. Feature Detection . . . . . . . . . . . . . . . . . 18
Appendix C. Upload Metadata . . . . . . . . . . . . . . . . . . 20 Appendix C. Upload Metadata . . . . . . . . . . . . . . . . . . 20
Appendix D. FAQ . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix D. FAQ . . . . . . . . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
F.1. Since draft-ietf-httpbis-resumable-upload-01 . . . . . . 21 F.1. Since draft-ietf-httpbis-resumable-upload-02 . . . . . . 21
F.2. Since draft-ietf-httpbis-resumable-upload-00 . . . . . . 21 F.2. Since draft-ietf-httpbis-resumable-upload-01 . . . . . . 21
F.3. Since draft-tus-httpbis-resumable-uploads-protocol-02 . . 21 F.3. Since draft-ietf-httpbis-resumable-upload-00 . . . . . . 21
F.4. Since draft-tus-httpbis-resumable-uploads-protocol-01 . . 21 F.4. Since draft-tus-httpbis-resumable-uploads-protocol-02 . . 21
F.5. Since draft-tus-httpbis-resumable-uploads-protocol-00 . . 21 F.5. Since draft-tus-httpbis-resumable-uploads-protocol-01 . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 F.6. Since draft-tus-httpbis-resumable-uploads-protocol-00 . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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
requests (see Section 14 of [HTTP]) support this concept of resumable requests (see Section 14 of [HTTP]) support this concept of resumable
skipping to change at page 3, line 45 skipping to change at page 3, line 46
process of sending additional parts of a representation using process of sending additional parts of a representation using
subsequent HTTP requests from client to server is herein referred to subsequent HTTP requests from client to server is herein referred to
as a resumable upload. as a resumable upload.
Connection interruptions are common and the absence of a standard Connection interruptions are common and the absence of a standard
mechanism for resumable uploads has lead to a proliferation of custom mechanism for resumable uploads has lead to a proliferation of custom
solutions. Some of those use HTTP, while others rely on other solutions. Some of those use HTTP, while others rely on other
transfer mechanisms entirely. An HTTP-based standard solution is transfer mechanisms entirely. An HTTP-based standard solution is
desirable for such a common class of problem. desirable for such a common class of problem.
This document defines an optional mechanism for HTTP than enables This document defines an optional mechanism for HTTP that enables
resumable uploads in a way that is backwards-compatible with resumable uploads in a way that is backwards-compatible with
conventional HTTP uploads. When an upload is interrupted, clients conventional HTTP uploads. When an upload is interrupted, clients
can send subsequent requests to query the server state and use this can send subsequent requests to query the server state and use this
information to the send remaining data. Alternatively, they can information to send the remaining data. Alternatively, they can
cancel the upload entirely. Different from ranged downloads, this cancel the upload entirely. Different from ranged downloads, this
protocol does not support transferring different parts of the same protocol does not support transferring different parts of the same
representation in parallel. representation in parallel.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at page 5, line 12 skipping to change at page 5, line 12
resource URL via the Location header field (Section 10.2.2 of resource URL via the Location header field (Section 10.2.2 of
[HTTP]). [HTTP]).
Client Server Client Server
| | | |
| POST | | POST |
|------------------------------------------->| |------------------------------------------->|
| | | |
| | Reserve resources | | Reserve resources
| | for upload | | for upload
| |------------------ | |-----------------.
| | | | | |
| |<----------------- | |<----------------'
| | | |
| 104 Upload Resumption Supported | | 104 Upload Resumption Supported |
| with upload resouce URL | | with upload resouce URL |
|<-------------------------------------------| |<-------------------------------------------|
| | | |
| Flow Interrupted | | Flow Interrupted |
|------------------------------------------->| |------------------------------------------->|
| | | |
Figure 1: Upload Creation Figure 1: Upload Creation
skipping to change at page 8, line 11 skipping to change at page 8, line 11
true. This header field can be used for request identification by a true. This header field can be used for request identification by a
server. The request MUST NOT include the "Upload-Offset" header server. The request MUST NOT include the "Upload-Offset" header
field. field.
If the request is valid, the server SHOULD create an upload resource. If the request is valid, the server SHOULD create an upload resource.
Then, the server MUST include the "Location" header field in the Then, the server MUST include the "Location" header field in the
response and set its value to the URL of the upload resource. The response and set its value to the URL of the upload resource. The
client MAY use this URL for offset retrieval (Section 5), upload client MAY use this URL for offset retrieval (Section 5), upload
append (Section 6), and upload cancellation (Section 7). append (Section 6), and upload cancellation (Section 7).
Once the upload resource is available, the target resource MAY send Once the upload resource is available and while the request content
an informational response with a "104 (Upload Resumption Supported)" is being uploaded, the target resource MAY send one or more
status code to the client while the request content is being informational responses with a "104 (Upload Resumption Supported)"
uploaded. In this informational response, the "Location" header status code to the client. In the first informational response, the
field MUST be set to the upload resource. "Location" header field MUST be set to the URL pointing to the upload
resource. In subsequent informational responses, the "Location"
header field MUST NOT be set. An informational response MAY contain
the "Upload-Offset" header field with the current upload offset as
the value to inform the client about the upload progress. In
subsequent informational responses, the upload offset MUST NOT be
smaller than in previous informational responses. In addition, later
offset retrievals (Section 5) MUST NOT receive an upload offset that
is less than the offset reported in the latest informational
response, allowing the client to free associated resources.
The server MUST send the "Upload-Offset" header field in the response The server MUST send the "Upload-Offset" header field in the response
if it considers the upload active, either when the response is a if it considers the upload active, either when the response is a
success (e.g. "201 (Created)"), or when the response is a failure success (e.g. "201 (Created)"), or when the response is a failure
(e.g. "409 (Conflict)"). The "Upload-Offset" field value MUST be (e.g. "409 (Conflict)"). The "Upload-Offset" field value MUST be
equal to the end offset of the entire upload, or the begin offset of equal to the end offset of the entire upload, or the begin offset of
the next chunk if the upload is still incomplete. The client SHOULD the next chunk if the upload is still incomplete. The client SHOULD
consider the upload failed if the response has a status code that consider the upload failed if the response has a status code that
indicates a success but the offset indicated in the "Upload-Offset" indicates a success but the offset indicated in the "Upload-Offset"
field value does not equal the total of begin offset plus the number field value does not equal the total of begin offset plus the number
skipping to change at page 9, line 5 skipping to change at page 9, line 7
false in the request, the server MUST acknowledge it by responding false in the request, the server MUST acknowledge it by responding
with the "201 (Created)" status code and an "Upload-Complete" header with the "201 (Created)" status code and an "Upload-Complete" header
value set to false. value set to false.
If the request includes an "Upload-Complete" field value set to true If the request includes an "Upload-Complete" field value set to true
and a valid "Content-Length" header field, the client attempts to and a valid "Content-Length" header field, the client attempts to
upload a fixed-length resource in one request. In this case, the upload a fixed-length resource in one request. In this case, the
upload's final size is the "Content-Length" field value and the upload's final size is the "Content-Length" field value and the
server MUST record it to ensure its consistency. server MUST record it to ensure its consistency.
:method: POST POST /upload HTTP/1.1
:scheme: https Host: example.com
:authority: example.com Upload-Draft-Interop-Version: 4
:path: /upload Upload-Complete: ?1
upload-draft-interop-version: 4 Content-Length: 100
upload-complete: ?1
content-length: 100
[content (100 bytes)] [content (100 bytes)]
:status: 104 HTTP/1.1 104 Upload Resumption Supported
upload-draft-interop-version: 4 Upload-Draft-Interop-Version: 4
location: https://example.com/upload/b530ce8ff Location: https://example.com/upload/b530ce8ff
:status: 201 HTTP/1.1 104 Upload Resumption Supported
location: https://example.com/upload/b530ce8ff Upload-Draft-Interop-Version: 4
upload-offset: 100 Upload-Offset: 50
HTTP/1.1 201 Created
Location: https://example.com/upload/b530ce8ff
Upload-Offset: 100
POST /upload HTTP/1.1
Host: example.com
Upload-Draft-Interop-Version: 4
Upload-Complete: ?0
Content-Length: 25
:method: POST
:scheme: https
:authority: example.com
:path: /upload
upload-draft-interop-version: 4
upload-complete: ?0
content-length: 25
[partial content (25 bytes)] [partial content (25 bytes)]
:status: 201 HTTP/1.1 201 Created
location: https://example.com/upload/b530ce8ff Location: https://example.com/upload/b530ce8ff
upload-complete: ?0 Upload-Complete: ?0
upload-offset: 25 Upload-Offset: 25
If the client received an informational response with the upload URL If the client received an informational response with the upload URL
in the Location field value, it MAY automatically attempt upload in the Location field value, it MAY automatically attempt upload
resumption when the connection is terminated unexpectedly, or if a resumption when the connection is terminated unexpectedly, or if a
5xx status is received. The client SHOULD NOT automatically retry if 5xx status is received. The client SHOULD NOT automatically retry if
it receives a 4xx status code. it receives a 4xx status code.
File metadata can affect how servers might act on the uploaded file. File metadata can affect how servers might act on the uploaded file.
Clients can send representation metadata (see Section 8.3 of [HTTP]) Clients can send representation metadata (see Section 8.3 of [HTTP])
in the request that starts an upload. Servers MAY interpret this in the request that starts an upload. Servers MAY interpret this
skipping to change at page 12, line 18 skipping to change at page 12, line 21
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
content it has already sent, the upload MUST be considered a failure. content it has already sent, the upload MUST be considered a failure.
The client MAY cancel the upload (Section 7) after rejecting the The client MAY cancel the upload (Section 7) after rejecting the
offset. offset.
:method: HEAD HEAD /upload/b530ce8ff HTTP/1.1
:scheme: https Host: example.com
:authority: example.com Upload-Draft-Interop-Version: 4
:path: /upload/b530ce8ff
upload-draft-interop-version: 4
:status: 204 HTTP/1.1 204 No Content
upload-offset: 100 Upload-Offset: 100
upload-complete: ?0 Upload-Complete: ?0
cache-control: no-store Cache-Control: no-store
The client SHOULD NOT automatically retry if a client error status The client SHOULD NOT automatically retry if a client error status
code between 400 and 499 (inclusive) is received. code between 400 and 499 (inclusive) is received.
6. Upload Append 6. Upload Append
Upload appending is used for resuming an existing upload. Upload appending is used for resuming an existing upload.
The request MUST use the "PATCH" method and be sent to the upload The request MUST use the "PATCH" method and be sent to the upload
resource. The "Upload-Offset" field value (Section 8.1) MUST be set resource. The "Upload-Offset" field value (Section 8.1) MUST be set
skipping to change at page 13, line 18 skipping to change at page 13, line 21
parallel, the server can assume that the previous attempt has already parallel, the server can assume that the previous attempt has already
failed. Therefore, the server MAY abruptly terminate the previous failed. Therefore, the server MAY abruptly terminate the previous
HTTP connection or stream. HTTP connection or stream.
If the offset indicated by the "Upload-Offset" field value does not If the offset indicated by the "Upload-Offset" field value does not
match the offset provided by the immediate previous offset retrieval match the offset provided by the immediate previous offset retrieval
(Section 5), or the end offset of the immediate previous incomplete (Section 5), or the end offset of the immediate previous incomplete
successful transfer, the server MUST respond with a "409 (Conflict)" successful transfer, the server MUST respond with a "409 (Conflict)"
status code. status code.
While the request content is being uploaded, the target resource MAY
send one or more informational responses with a "104 (Upload
Resumption Supported)" status code to the client. These
informational responses MUST NOT contain the "Location" header field.
They MAY include the "Upload-Offset" header field with the current
upload offset as the value to inform the client about the upload
progress. The same restrictions on the "Upload-Offset" header field
in informational responses from the upload creation (Section 4)
apply.
The server MUST send the "Upload-Offset" header field in the response The server MUST send the "Upload-Offset" header field in the response
if it considers the upload active, either when the response is a if it considers the upload active, either when the response is a
success (e.g. "201 (Created)"), or when the response is a failure success (e.g. "201 (Created)"), or when the response is a failure
(e.g. "409 (Conflict)"). The value MUST be equal to the end offset (e.g. "409 (Conflict)"). The value MUST be equal to the end offset
of the entire upload, or the begin offset of the next chunk if the of the entire upload, or the begin offset of the next chunk if the
upload is still incomplete. The client SHOULD consider the upload upload is still incomplete. The client SHOULD consider the upload
failed if the status code indicates a success but the offset failed if the status code indicates a success but the offset
indicated by the "Upload-Offset" field value does not equal the total indicated by the "Upload-Offset" field value does not equal the total
of begin offset plus the number of bytes uploaded in the request. of begin offset plus the number of bytes uploaded in the request.
skipping to change at page 14, line 5 skipping to change at page 14, line 16
and a valid "Content-Length" header field, the client attempts to and a valid "Content-Length" header field, the client attempts to
upload the remaining resource in one request. In this case, the upload the remaining resource in one request. In this case, the
upload's final size is the sum of the upload's offset and the upload's final size is the sum of the upload's offset and the
"Content-Length" header field. If the server does not have a record "Content-Length" header field. If the server does not have a record
of the upload's final size from creation or the previous append, the of the upload's final size from creation or the previous append, the
server MUST record the upload's final size to ensure its consistency. server MUST record the upload's final size to ensure its consistency.
If the server does have a previous record, that value MUST match the If the server does have a previous record, that value MUST match the
upload's final size. If they do not match, the server MUST reject upload's final size. If they do not match, the server MUST reject
the request with a "400 (Bad Request)" status code. the request with a "400 (Bad Request)" status code.
:method: PATCH PATCH /upload/b530ce8ff HTTP/1.1
:scheme: https Host: example.com
:authority: example.com Upload-Offset: 100
:path: /upload/b530ce8ff Upload-Draft-Interop-Version: 4
upload-offset: 100 Content-Length: 100
upload-draft-interop-version: 4
content-length: 100
[content (100 bytes)] [content (100 bytes)]
:status: 201 HTTP/1.1 201 Created
upload-offset: 200 Upload-Offset: 200
The client MAY automatically attempt upload resumption when the The client MAY automatically attempt upload resumption when the
connection is terminated unexpectedly, or if a server error status connection is terminated unexpectedly, or if a server error status
code between 500 and 599 (inclusive) is received. The client SHOULD code between 500 and 599 (inclusive) is received. The client SHOULD
NOT automatically retry if a client error status code between 400 and NOT automatically retry if a client error status code between 400 and
499 (inclusive) is received. 499 (inclusive) is received.
7. Upload Cancellation 7. Upload Cancellation
If the client wants to terminate the transfer without the ability to If the client wants to terminate the transfer without the ability to
skipping to change at page 15, line 5 skipping to change at page 15, line 15
The server MAY terminate any in-flight requests to the upload The server MAY terminate any in-flight requests to the upload
resource before sending the response by abruptly terminating their resource before sending the response by abruptly terminating their
HTTP connection(s) or stream(s). HTTP connection(s) or stream(s).
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.
If the server does not support cancellation, it MUST respond with a If the server does not support cancellation, it MUST respond with a
"405 (Method Not Allowed)" status code. "405 (Method Not Allowed)" status code.
:method: DELETE DELETE /upload/b530ce8ff HTTP/1.1
:scheme: https Host: example.com
:authority: example.com Upload-Draft-Interop-Version: 4
:path: /upload/b530ce8ff
upload-draft-interop-version: 4
:status: 204 HTTP/1.1 204 No Content
8. Header Fields 8. Header Fields
8.1. Upload-Offset 8.1. Upload-Offset
The "Upload-Offset" request and response header field indicates the The "Upload-Offset" request and response header field indicates the
resumption offset of corresponding upload, counted in bytes. The resumption offset of corresponding upload, counted in bytes. The
"Upload-Offset" field value is an Integer. "Upload-Offset" field value is an Integer.
8.2. Upload-Complete 8.2. Upload-Complete
The "Upload-Complete" request and response header field indicates The "Upload-Complete" request and response header field indicates
whether the corresponding upload is considered complete. The whether the corresponding upload is considered complete. The
"Upload-Complete" field value is a Boolean. "Upload-Complete" field value is a Boolean.
The "Upload-Complete" header field MUST only by used if support by The "Upload-Complete" header field MUST only be used if support by
the resource is known to the client (Section 4.1). the resource is known to the client (Section 4.1).
9. Redirection 9. 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 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
skipping to change at page 15, line 46 skipping to change at page 16, line 10
use new permanent URI for subsequent requests. If the client use 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).
10. Security Considerations 10. 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.
11. IANA Considerations Some servers or intermediaries provide scanning of content uploaded
by clients. Any scanning mechanism that relies on receiving a
This specification registers the following entry in the Permanent complete file in a single request message can be defeated by
Message Header Field Names registry established by [RFC3864]: resumable uploads because content can be split across multiple
messages. Servers or intermediaries wishing to perform content
Header field name: Upload-Offset, Upload-Complete scanning SHOULD consider how resumable uploads can circumvent
scanning and take appropriate measures. Possible strategies include
Applicable protocol: http waiting for the upload to complete before scanning a full file, or
disabling resumable uploads.
Status: standard
Author/change controller: IETF 11. IANA Considerations
Specification: This document IANA is asked to register the following entries in the "Hypertext
Transfer Protocol (HTTP) Field Name Registry":
Related information: n/a +-----------------+-----------+------------------------------+
| Field Name | Status | Reference |
+-----------------+-----------+------------------------------+
| Upload-Complete | permanent | Section 8.2 of this document |
| | | |
| Upload-Offset | permanent | Section 8.1 of this document |
+-----------------+-----------+------------------------------+
This specification registers the following entry in the "HTTP Status IANA is asked to register the following entry in the "HTTP Status
Codes" registry: Codes" registry:
Code: 104 (suggested value) Value: 104 (suggested value)
Description: Upload Resumption Supported Description: Upload Resumption Supported
Specification: This document Specification: This document
12. References 12. References
12.1. Normative References 12.1. Normative References
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004,
<https://www.rfc-editor.org/info/rfc3864>.
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field
in the Hypertext Transfer Protocol (HTTP)", RFC 6266, in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
DOI 10.17487/RFC6266, June 2011, DOI 10.17487/RFC6266, June 2011,
<https://www.rfc-editor.org/info/rfc6266>. <https://www.rfc-editor.org/info/rfc6266>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[STRUCTURED-FIELDS] [STRUCTURED-FIELDS]
skipping to change at page 21, line 5 skipping to change at page 21, line 9
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-01 F.1. Since draft-ietf-httpbis-resumable-upload-02
o Add upload progress notifications via informational responses.
o Add security consideration regarding request filtering.
F.2. 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.2. Since draft-ietf-httpbis-resumable-upload-00 F.3. 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.3. Since draft-tus-httpbis-resumable-uploads-protocol-02 F.4. Since draft-tus-httpbis-resumable-uploads-protocol-02
None None
F.4. Since draft-tus-httpbis-resumable-uploads-protocol-01 F.5. 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.5. Since draft-tus-httpbis-resumable-uploads-protocol-00 F.6. 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 Ltd Transloadit
Email: marius@transloadit.com Email: marius@transloadit.com
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: lucaspardue.24.7@gmail.com Email: lucas@lucaspardue.com
 End of changes. 45 change blocks. 
102 lines changed or deleted 125 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/