From a58a75c3866a1ccf412b435f13199f13f2392649 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Thu, 26 Mar 2026 15:20:45 -0700 Subject: [PATCH 01/16] Redefine Upload-Complete on the server side --- draft-ietf-httpbis-resumable-upload.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 4a868fcfb..4f9cdeb71 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -204,7 +204,7 @@ In some cases, clients might prefer to upload a representation as a series of pa This example shows how the client, communicating with a resource known to support resumable upload, can upload parts of a representation incrementally. -1) The client is aware that the targetted resource supports resumable uploads and therefore starts the upload with the `Upload-Complete` field value set to false and the first part of the representation. +1) The client is aware that the targeted resource supports resumable uploads and therefore starts the upload with the `Upload-Complete` field value set to false and the first part of the representation. ~~~ aasvg Client Server @@ -317,10 +317,12 @@ The `Upload-Offset` header field in responses serves as an acknowledgement of th An upload is incomplete until it is explicitly marked as completed by the client. After this point, no representation data can be appended anymore. -The `Upload-Complete` request and response header field conveys the completeness state. `Upload-Complete` is an Item Structured Header Field ({{STRUCTURED-FIELDS}}). Its value is a Boolean ({{Section 3.3.6 of STRUCTURED-FIELDS}}) and indicates whether the upload is complete or not. Other values MUST cause the entire header field to be ignored. +The `Upload-Complete` request header field conveys the completeness state. `Upload-Complete` is an Item Structured Header Field ({{STRUCTURED-FIELDS}}). Its value is a Boolean ({{Section 3.3.6 of STRUCTURED-FIELDS}}) and indicates whether the upload is complete or not. Other values MUST cause the entire header field to be ignored. An upload is marked as completed if a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) included the `Upload-Complete` header field with a true value and the request content was fully processed. +The `Upload-Complete` response header field distinguishes the response from the initial targeted resource or the temporary upload resource. The value of true means the response is from the the initial targeted resource, and the value of false means the response is from the temporary upload resource. It is worth noting that `Upload-Complete` can be true even if the upload is not complete if the targeted resource decides to generate an early response. + ### Length {#upload-length} The length of an upload is the number of bytes of representation data that the client intends to upload. @@ -485,7 +487,7 @@ Location: https://example.com/upload/0587fa44b HTTP/1.1 500 Internal Server Error ~~~ -D) The following example shows an upload creation being rejected by the server because uploads to the targetted resource are not allowed. The client cannot continue the upload. +D) The following example shows an upload creation being rejected by the server because uploads to the targeted resource are not allowed. The client cannot continue the upload. ~~~ http-message POST /upload-not-allowed HTTP/1.1 @@ -523,7 +525,7 @@ If the client received a response with a A successful response to a `HEAD` request against an upload resource - MUST include the offset in the `Upload-Offset` header field ({{upload-offset}}), -- MUST include the completeness state in the `Upload-Complete` header field ({{upload-complete}}), +- MUST include the `Upload-Complete` header field ({{upload-complete}}), - MUST include the length in the `Upload-Length` header field, unless the client has not supplied one, by providing the corresponding headers as described in ({{upload-length}}), - MUST indicate the limits in the `Upload-Limit` header field ({{upload-limit}}), and - SHOULD include the `Cache-Control` header field with the value `no-store` to prevent HTTP caching ({{CACHING}}). @@ -1000,6 +1002,7 @@ Reference: * Clear up different responsibilities of server and upload resource. * Relax recommendations on client handling greater offsets. * Clarify client behavior for 413 responses. +* Redefine Upload-Complete on the server side ## Since draft-ietf-httpbis-resumable-upload-10 {:numbered="false"} From 3c16d6c512cefb0cc4af414032216679c6d724f6 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Fri, 1 May 2026 18:07:05 -0700 Subject: [PATCH 02/16] Feedback Co-authored-by: Grant Gryczan --- draft-ietf-httpbis-resumable-upload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 4f9cdeb71..3378c8154 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -321,7 +321,7 @@ The `Upload-Complete` request header field conveys the completeness state. `Uplo An upload is marked as completed if a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) included the `Upload-Complete` header field with a true value and the request content was fully processed. -The `Upload-Complete` response header field distinguishes the response from the initial targeted resource or the temporary upload resource. The value of true means the response is from the the initial targeted resource, and the value of false means the response is from the temporary upload resource. It is worth noting that `Upload-Complete` can be true even if the upload is not complete if the targeted resource decides to generate an early response. +The `Upload-Complete` response header field distinguishes the response from the initial targeted resource or the temporary upload resource. The value of true means the response is from the initial targeted resource, and the value of false means the response is from the temporary upload resource. It is worth noting that `Upload-Complete` can be true even when the full representation data was not received if the targeted resource decides to generate an early response. ### Length {#upload-length} From 582304fa382ca46469ea17da6db219cbecf0762a Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Fri, 1 May 2026 18:17:17 -0700 Subject: [PATCH 03/16] Update example --- draft-ietf-httpbis-resumable-upload.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 3378c8154..f88bed92c 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -487,20 +487,21 @@ Location: https://example.com/upload/0587fa44b HTTP/1.1 500 Internal Server Error ~~~ -D) The following example shows an upload creation being rejected by the server because uploads to the targeted resource are not allowed. The client cannot continue the upload. +D) The following example shows an upload creation being rejected by the server because uploads to the targeted resource are not allowed. The Upload-Complete header in the response is set to true since the server is uninterested in receiving the full representation and the upload is complete in its perspective. The client cannot continue the upload. ~~~ http-message POST /upload-not-allowed HTTP/1.1 Host: example.com -Upload-Complete: ?1 -Content-Length: 123456789 +Upload-Complete: ?0 +Content-Length: 23456789 Upload-Length: 123456789 -[content (123456789 bytes)] +[content (23456789 bytes)] ~~~ ~~~ http-message HTTP/1.1 405 Method Not Allowed +Upload-Complete: ?1 ~~~ ## Offset Retrieval {#offset-retrieving} From e65ceebbf1c812ad6f47e59b3181ce36aa784f28 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Tue, 12 May 2026 11:18:50 -0700 Subject: [PATCH 04/16] Clarify Upload-Complete semantics --- draft-ietf-httpbis-resumable-upload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index c62ed5c7d..ff81e5cff 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -321,7 +321,7 @@ The `Upload-Complete` request header field conveys the completeness state. `Uplo An upload is marked as completed if a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) included the `Upload-Complete` header field with a true value and the request content was fully processed. -The `Upload-Complete` response header field distinguishes the response from the initial targeted resource or the temporary upload resource. The value of true means the response is from the initial targeted resource, and the value of false means the response is from the temporary upload resource. It is worth noting that `Upload-Complete` can be true even when the full representation data was not received if the targeted resource decides to generate an early response. +The `Upload-Complete` response header field distinguishes the response from the initial targeted resource or the temporary upload resource. The value of true means the response is from the initial targeted resource, and that the semantics of the targeted resource apply; the value of false means the response is from the temporary upload resource, and the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not received if the targeted resource decides to generate an early response. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. ### Length {#upload-length} From 4cca6a2b81465d7ec3e0f8f13a82ce41b5656fbe Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Tue, 12 May 2026 12:27:43 -0700 Subject: [PATCH 05/16] Stop mentioning the upload resource --- draft-ietf-httpbis-resumable-upload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 5b564bc57..1eb19b95c 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -321,7 +321,7 @@ The `Upload-Complete` request header field conveys the completeness state. `Uplo An upload is marked as completed if a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) included the `Upload-Complete` header field with a true value and the request content was fully processed. -The `Upload-Complete` response header field distinguishes the response from the initial targeted resource or the temporary upload resource. The value of true means the response is from the initial targeted resource, and that the semantics of the targeted resource apply; the value of false means the response is from the temporary upload resource, and the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not received if the targeted resource decides to generate an early response. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. +The `Upload-Complete` response header field signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not transmitted in the case that the server decides decides to generate an early response when processing the targeted resource. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. ### Length {#upload-length} From e3049541113b94ca9886b6a8cb0364551b708223 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Tue, 12 May 2026 12:40:35 -0700 Subject: [PATCH 06/16] Update draft-ietf-httpbis-resumable-upload.md Co-authored-by: Grant Gryczan --- draft-ietf-httpbis-resumable-upload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 1eb19b95c..99652c459 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -321,7 +321,7 @@ The `Upload-Complete` request header field conveys the completeness state. `Uplo An upload is marked as completed if a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) included the `Upload-Complete` header field with a true value and the request content was fully processed. -The `Upload-Complete` response header field signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not transmitted in the case that the server decides decides to generate an early response when processing the targeted resource. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. +The `Upload-Complete` response header field signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not transmitted in the case that the server decides to generate an early response when processing the targeted resource. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. ### Length {#upload-length} From 3a994a43432a6ebb9e4843f992434b49e38bed26 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Tue, 12 May 2026 15:34:50 -0700 Subject: [PATCH 07/16] Review feedback --- draft-ietf-httpbis-resumable-upload.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 99652c459..4ff5ce982 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -315,7 +315,7 @@ The `Upload-Offset` header field in responses serves as an acknowledgement of th ### Completeness {#upload-complete} -An upload is incomplete until it is explicitly marked as completed by the client. After this point, no representation data can be appended anymore. +An upload is incomplete until it is explicitly marked as completed by the client or the server. After this point, no representation data can be appended anymore. The `Upload-Complete` request header field conveys the completeness state. `Upload-Complete` is an Item Structured Header Field ({{STRUCTURED-FIELDS}}). Its value is a Boolean ({{Section 3.3.6 of STRUCTURED-FIELDS}}) and indicates whether the upload is complete or not. Other values MUST cause the entire header field to be ignored. @@ -414,6 +414,8 @@ While the request content is being processed, the server MAY send multiple inter Where a response requires a `Location` header field to be included, all interim and final response messages for the same request MUST contain an identical `Location` value. However, final responses including the `Upload-Complete: ?1` header field are exempt from this requirement because they are the result of processing the transferred representation and the `Location` value does not necessarily represent the upload location. Where the `Location` value is expected to be identical across multiple messages, clients SHOULD verify this. If verification fails, clients SHOULD abort the current request and cancel the upload ({{upload-cancellation}}). +The server SHOULD include the `Upload-Complete` ({{upload-complete}}) header field in the response to indicate whether it is the result of processing the uploaded representation. + The server might not process the entire request content when the upload is interrupted, for example because of dropped connection or canceled request. In this case, the server SHOULD append as much of the request content as possible to the upload resource, allowing the client to resume the upload from where it was interrupted. In addition, the upload resource MUST NOT be considered complete then. ### Examples {#upload-creation-example} @@ -441,6 +443,7 @@ Upload-Offset: 23456789 HTTP/1.1 200 OK Location: https://example.com/upload/b530ce8ff +Upload-Complete: ?1 Upload-Limit: max-size=1234567890 Content-Type: application/json @@ -465,6 +468,7 @@ Location: https://example.com/upload/3fd4994ad HTTP/1.1 201 Created Location: https://example.com/upload/3fd4994ad +Upload-Complete: ?0 Upload-Limit: max-size=1234567890 ~~~ @@ -526,7 +530,7 @@ If the client received a response with a A successful response to a `HEAD` request against an upload resource - MUST include the offset in the `Upload-Offset` header field ({{upload-offset}}), -- MUST include the `Upload-Complete` header field ({{upload-complete}}), +- MUST include the `Upload-Complete` header field ({{upload-complete}}) indicating whether a final response was produced from processing the uploaded representation, - MUST include the length in the `Upload-Length` header field, unless the client has not supplied one, by providing the corresponding headers as described in ({{upload-length}}), - MUST indicate the limits in the `Upload-Limit` header field ({{upload-limit}}), and - SHOULD include the `Cache-Control` header field with the value `no-store` to prevent HTTP caching ({{CACHING}}). @@ -613,6 +617,8 @@ The server MUST record the length according to {{upload-length}} if the `Upload- While the request content is being processed, the server SHOULD send interim responses with a `104 (Upload Resumption Supported)` status code and the `Upload-Offset` header field set to the current offset to inform the client about the upload progress. These interim responses MUST NOT include the `Location` header field. +The server SHOULD include the `Upload-Complete` ({{upload-complete}}) header field in the response to indicate whether it is the result of processing the uploaded representation. + ### Examples {#upload-appending-example} A) The following example shows an upload append request. The client transfers the next 3456789 bytes at an offset of 20000000 and does not indicate that the upload is then completed. The server generates one interim response, when the offset reached 21728394 bytes, and finally acknowledges the new offset: From 9a005bf7526befe983164d966b2a99d0058f2b15 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Tue, 12 May 2026 18:16:49 -0700 Subject: [PATCH 08/16] Change example --- draft-ietf-httpbis-resumable-upload.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 4ff5ce982..a22507526 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -491,20 +491,21 @@ Location: https://example.com/upload/0587fa44b HTTP/1.1 500 Internal Server Error ~~~ -D) The following example shows an upload creation being rejected by the server because uploads to the targeted resource are not allowed. The Upload-Complete header in the response is set to true since the server is uninterested in receiving the full representation and the upload is complete in its perspective. The client cannot continue the upload. +D) The following example shows an upload creation being rejected by the server because the request content cannot be decoded. The Upload-Complete header in the response is set to true since the server is uninterested in receiving the full representation after the decoding failure and the upload is complete in its perspective. The client cannot continue the upload. ~~~ http-message -POST /upload-not-allowed HTTP/1.1 +POST /upload-gzip HTTP/1.1 Host: example.com Upload-Complete: ?0 Content-Length: 23456789 Upload-Length: 123456789 +Content-Encoding: gzip -[content (23456789 bytes)] +[corrupted gzip content] ~~~ ~~~ http-message -HTTP/1.1 405 Method Not Allowed +HTTP/1.1 400 Bad Request Upload-Complete: ?1 ~~~ From acb6d27c752f5e90a7031dad8b6c5a1396db9c62 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Tue, 12 May 2026 18:26:30 -0700 Subject: [PATCH 09/16] Update draft-ietf-httpbis-resumable-upload.md Co-authored-by: Lucas Pardue --- draft-ietf-httpbis-resumable-upload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index a22507526..bfb561841 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -315,7 +315,7 @@ The `Upload-Offset` header field in responses serves as an acknowledgement of th ### Completeness {#upload-complete} -An upload is incomplete until it is explicitly marked as completed by the client or the server. After this point, no representation data can be appended anymore. +An upload is incomplete until it is explicitly marked as completed by the client or the server. After this point, no more representation data can be appended. The `Upload-Complete` request header field conveys the completeness state. `Upload-Complete` is an Item Structured Header Field ({{STRUCTURED-FIELDS}}). Its value is a Boolean ({{Section 3.3.6 of STRUCTURED-FIELDS}}) and indicates whether the upload is complete or not. Other values MUST cause the entire header field to be ignored. From e26ee2cb517e96a074cca7e2d5ac9a769a58ad29 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Tue, 12 May 2026 18:48:17 -0700 Subject: [PATCH 10/16] Rephrase completeness --- draft-ietf-httpbis-resumable-upload.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index bfb561841..3dcbb24fe 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -317,11 +317,11 @@ The `Upload-Offset` header field in responses serves as an acknowledgement of th An upload is incomplete until it is explicitly marked as completed by the client or the server. After this point, no more representation data can be appended. -The `Upload-Complete` request header field conveys the completeness state. `Upload-Complete` is an Item Structured Header Field ({{STRUCTURED-FIELDS}}). Its value is a Boolean ({{Section 3.3.6 of STRUCTURED-FIELDS}}) and indicates whether the upload is complete or not. Other values MUST cause the entire header field to be ignored. +The `Upload-Complete` request and response header field conveys the completeness state. `Upload-Complete` is an Item Structured Header Field ({{STRUCTURED-FIELDS}}). Its value is a Boolean ({{Section 3.3.6 of STRUCTURED-FIELDS}}) and indicates whether the upload is complete or not. Other values MUST cause the entire header field to be ignored. -An upload is marked as completed if a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) included the `Upload-Complete` header field with a true value and the request content was fully processed. +An upload is marked as completed either when a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) included the `Upload-Complete` header field with a true value and the request content was fully processed, or when the server sends a response included the `Upload-Complete` header field with a true value, whichever happens first. -The `Upload-Complete` response header field signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not transmitted in the case that the server decides to generate an early response when processing the targeted resource. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. +When used in a response, `Upload-Complete` signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not transmitted in the case that the server decides to generate an early response when processing the targeted resource. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. ### Length {#upload-length} From 1f3d8457978c81000e3c11327e64babf0d5edcf2 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Wed, 13 May 2026 10:04:51 -0700 Subject: [PATCH 11/16] Update draft-ietf-httpbis-resumable-upload.md Co-authored-by: Grant Gryczan --- draft-ietf-httpbis-resumable-upload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 2f970a058..5d8187251 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -319,7 +319,7 @@ An upload is incomplete until it is explicitly marked as completed by the client The `Upload-Complete` request and response header field conveys the completeness state. `Upload-Complete` is an Item Structured Header Field ({{STRUCTURED-FIELDS}}). Its value is a Boolean ({{Section 3.3.6 of STRUCTURED-FIELDS}}) and indicates whether the upload is complete or not. Other values MUST cause the entire header field to be ignored. -An upload is marked as completed either when a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) included the `Upload-Complete` header field with a true value and the request content was fully processed, or when the server sends a response included the `Upload-Complete` header field with a true value, whichever happens first. +An upload is marked as completed either when a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) includes the `Upload-Complete` header field with a true value and the request content was fully processed, or when a response includes the `Upload-Complete` header field with a true value. When used in a response, `Upload-Complete` signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not transmitted in the case that the server decides to generate an early response when processing the targeted resource. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. From 0a063621281578f59008fc38112e4b3d8bc4dc9c Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Wed, 13 May 2026 10:10:32 -0700 Subject: [PATCH 12/16] Add 104 to the example --- draft-ietf-httpbis-resumable-upload.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 5d8187251..ea88efffd 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -505,6 +505,9 @@ Content-Encoding: gzip ~~~ ~~~ http-message +HTTP/1.1 104 Upload Resumption Supported +Location: https://example.com/upload/6723cdf37 + HTTP/1.1 400 Bad Request Upload-Complete: ?1 ~~~ From dd85aadf5310cd7bae51a7a2ff91b821631ea2b4 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Thu, 14 May 2026 21:20:31 -0700 Subject: [PATCH 13/16] Update draft-ietf-httpbis-resumable-upload.md Co-authored-by: Grant Gryczan --- draft-ietf-httpbis-resumable-upload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index ea88efffd..d827223b7 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -491,7 +491,7 @@ Location: https://example.com/upload/0587fa44b HTTP/1.1 500 Internal Server Error ~~~ -D) The following example shows an upload creation being rejected by the server because the request content cannot be decoded. The Upload-Complete header in the response is set to true since the server is uninterested in receiving the full representation after the decoding failure and the upload is complete in its perspective. The client cannot continue the upload. +D) The following example shows an upload creation being rejected by the server because the request content cannot be decoded. The `Upload-Complete` header in the response is set to true since the server is uninterested in receiving the full representation after the decoding failure and the upload is complete in its perspective. The client cannot continue the upload. ~~~ http-message POST /upload-gzip HTTP/1.1 From 1332e9c8a9930f16b89dcf86b7c81c966c2bd34b Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Sat, 16 May 2026 13:17:20 -0700 Subject: [PATCH 14/16] Clarify Upload-Complete on 409 conflict --- draft-ietf-httpbis-resumable-upload.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index d827223b7..ee830c339 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -321,7 +321,7 @@ The `Upload-Complete` request and response header field conveys the completeness An upload is marked as completed either when a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) includes the `Upload-Complete` header field with a true value and the request content was fully processed, or when a response includes the `Upload-Complete` header field with a true value. -When used in a response, `Upload-Complete` signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not transmitted in the case that the server decides to generate an early response when processing the targeted resource. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. +When used in an upload creation response ({{upload-creation}}) or an upload append response ({{upload-appending}}), `Upload-Complete` signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not transmitted in the case that the server decides to generate an early response when processing the targeted resource. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. The `Upload-Complete` response header field can also be false if an invalid operation is performed on a completed upload. ### Length {#upload-length} @@ -589,7 +589,7 @@ A server applies a `PATCH` request with the `application/partial-upload` media t The server might not process the entire patch document when the upload is interrupted, for example because of a dropped connection or canceled request. In this case, the server SHOULD append as much of the patch document as possible to the upload resource, starting at its beginning and without discontinuities. Appending a continuous section starting at the patch document's beginning constitutes a successful PATCH as defined in {{Section 2 of PATCH}}. Saving the processed data allows the client to resume the upload from where it was interrupted. In addition, the upload resource MUST NOT be considered complete then. -If the `Upload-Offset` request header field value does not match the current offset ({{upload-offset}}), the server MUST reject the request with a `409 (Conflict)` status code. The response MUST include the correct offset in the `Upload-Offset` header field. The response can use the problem type {{PROBLEM}} of "https://iana.org/assignments/http-problem-types#mismatching-upload-offset" ({{mismatching-offset}}). +If the `Upload-Offset` request header field value does not match the current offset ({{upload-offset}}), the server MUST reject the request with a `409 (Conflict)` status code and the `Upload-Complete` header field set to false. The response MUST include the correct offset in the `Upload-Offset` header field. The response can use the problem type {{PROBLEM}} of "https://iana.org/assignments/http-problem-types#mismatching-upload-offset" ({{mismatching-offset}}). If the `Upload-Complete` request header field is set to true, the client intends to transfer the remaining representation data in one request. If the request content was fully processed, the upload is marked as complete and the server SHOULD generate the response that matches what the resource, that was targeted by the initial upload creation ({{upload-creation}}), would have generated if it had processed the entire representation in the initial request. However, the response MUST include the `Upload-Complete` header field with a true value, allowing clients to identify whether a response, in particular error responses, is related to the resumable upload itself or the processing of the uploaded representation. @@ -716,6 +716,8 @@ The following example shows an example response, where the resource's offset was HTTP/1.1 409 Conflict Content-Type: application/problem+json +Upload-Offset: 12500000 +Upload-Complete: ?0 { "type":"https://iana.org/assignments/http-problem-types#\ @@ -737,6 +739,7 @@ The following example shows an example response: HTTP/1.1 400 Bad Request Content-Type: application/problem+json +Upload-Complete: ?0 { "type":"https://iana.org/assignments/http-problem-types#\ From 43a069f7164c4af8ae6d7d58c4d02fdb842e60d7 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Sat, 16 May 2026 16:56:51 -0700 Subject: [PATCH 15/16] Update draft-ietf-httpbis-resumable-upload.md Co-authored-by: Grant Gryczan --- draft-ietf-httpbis-resumable-upload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index a362571ef..633ac8162 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -321,7 +321,7 @@ The `Upload-Complete` request and response header field conveys the completeness An upload is marked as completed either when a request for creating the upload resource ({{upload-creation}}) or appending to it ({{upload-appending}}) includes the `Upload-Complete` header field with a true value and the request content was fully processed, or when a response includes the `Upload-Complete` header field with a true value. -When used in an upload creation response ({{upload-creation}}) or an upload append response ({{upload-appending}}), `Upload-Complete` signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. It is worth noting that `Upload-Complete` can be true even when the full representation data was not transmitted in the case that the server decides to generate an early response when processing the targeted resource. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. The `Upload-Complete` response header field can also be false if an invalid operation is performed on a completed upload. +When used in an upload creation response ({{upload-creation}}) or an upload append response ({{upload-appending}}), `Upload-Complete` signals whether the response comes from the initial targeted resource. The value of true means that the semantics of the targeted resource apply, and the value of false means that the semantics of the resumable upload protocol apply. The client SHOULD NOT perform upload resumption to the upload resource after receiving a response with the `Upload-Complete` field value set to true. Note that `Upload-Complete` can be true even when the full representation data was not transmitted in the case that the server decides to generate an early response when processing the targeted resource. Also note that `Upload-Complete` can be false in response to an invalid operation performed on a completed upload. ### Length {#upload-length} From c7e1af30b956c30da7718c9b7a67f08714687697 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Mon, 18 May 2026 08:09:30 -0700 Subject: [PATCH 16/16] Update draft-ietf-httpbis-resumable-upload.md Co-authored-by: Grant Gryczan --- draft-ietf-httpbis-resumable-upload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 633ac8162..39ff9dcd7 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -497,7 +497,7 @@ Location: https://example.com/upload/0587fa44b HTTP/1.1 500 Internal Server Error ~~~ -D) The following example shows an upload creation being rejected by the server because the request content cannot be decoded. The `Upload-Complete` header in the response is set to true since the server is uninterested in receiving the full representation after the decoding failure and the upload is complete in its perspective. The client cannot continue the upload. +D) The following example shows an upload creation being rejected by the server because the request content cannot be decoded. The `Upload-Complete` header in the response is set to true since the server is uninterested in receiving the full representation after the decoding failure, and the upload is complete in its perspective. The client cannot continue the upload. ~~~ http-message POST /upload-gzip HTTP/1.1