From 2375783701d562efd3ebff69dd4672d4e9de8229 Mon Sep 17 00:00:00 2001 From: Grant Gryczan Date: Sun, 29 Mar 2026 14:23:25 -0400 Subject: [PATCH 1/7] RESUMABLE: Allow `max-age` limit to decrease as expected --- draft-ietf-httpbis-resumable-upload.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 4a868fcfb..9233fa444 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -361,7 +361,7 @@ The following key-value pairs are defined: `max-age`: : Specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response. After the resource's lifetime is reached, the server might make the upload resource inaccessible and a client SHOULD NOT attempt to access the upload resource as these requests will likely fail. The value is an Integer. -Clients usually discover limits through the `Upload-Limit` header field when the upload resource is created ({{upload-creation}}). Throughout the lifetime of the upload resource, these limits SHOULD NOT change in a way that causes failures for clients adhering to the initially discovered limits. In particular, whereas the values for `max-size`, `max-append-size`, and `max-age` can increase without harm, they SHOULD NOT decrease as they can cause ongoing uploads to fail. Similarly, the value for `min-append-size` SHOULD NOT increase. If the client discovers that it cannot continue the upload while adhering to the limits, it SHOULD stop the current request immediately and cancel the upload ({{upload-cancellation}}). +Clients usually discover limits through the `Upload-Limit` header field when the upload resource is created ({{upload-creation}}). Throughout the lifetime of the upload resource, these limits SHOULD NOT change in a way that causes failures for clients adhering to the initially discovered limits. In particular, whereas the values for `max-size` and `max-append-size` can increase without harm, they SHOULD NOT decrease as they can cause ongoing uploads to fail. Similarly, the value for `min-append-size` SHOULD NOT increase, and the value for `max-age` SHOULD NOT decrease enough to cause the upload resource's lifetime to end sooner. If the client discovers that it cannot continue the upload while adhering to the limits, it SHOULD stop the current request immediately and cancel the upload ({{upload-cancellation}}). Receivers of `Upload-Limit` parse the Dictionary as described in {{Section 4.2 of STRUCTURED-FIELDS}}. Where the Dictionary is successfully parsed, this document places two additional requirements on Dictionary members. First, a member with an unknown key MUST be ignored. Second, a member with a known key but a value of unexpected type MUST cause the entire `Upload-Limit` header field to be ignored, or alternatively the complete HTTP message MUST be treated as malformed. @@ -1000,6 +1000,7 @@ Reference: * Clear up different responsibilities of server and upload resource. * Relax recommendations on client handling greater offsets. * Clarify client behavior for 413 responses. +* Allow `max-age` limit to decrease as expected. ## Since draft-ietf-httpbis-resumable-upload-10 {:numbered="false"} From c216ae62e861978c4c57469dafd09fbaeb1bf7a3 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Tue, 12 May 2026 11:27:19 -0700 Subject: [PATCH 2/7] Switch to bullets --- draft-ietf-httpbis-resumable-upload.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 9233fa444..ed3292043 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -361,7 +361,11 @@ The following key-value pairs are defined: `max-age`: : Specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response. After the resource's lifetime is reached, the server might make the upload resource inaccessible and a client SHOULD NOT attempt to access the upload resource as these requests will likely fail. The value is an Integer. -Clients usually discover limits through the `Upload-Limit` header field when the upload resource is created ({{upload-creation}}). Throughout the lifetime of the upload resource, these limits SHOULD NOT change in a way that causes failures for clients adhering to the initially discovered limits. In particular, whereas the values for `max-size` and `max-append-size` can increase without harm, they SHOULD NOT decrease as they can cause ongoing uploads to fail. Similarly, the value for `min-append-size` SHOULD NOT increase, and the value for `max-age` SHOULD NOT decrease enough to cause the upload resource's lifetime to end sooner. If the client discovers that it cannot continue the upload while adhering to the limits, it SHOULD stop the current request immediately and cancel the upload ({{upload-cancellation}}). +Clients usually discover limits through the `Upload-Limit` header field when the upload resource is created ({{upload-creation}}). Throughout the lifetime of the upload resource, these limits SHOULD NOT change in a way that causes failures for clients adhering to the initially discovered limits. If the client discovers that it cannot continue the upload while adhering to the limits, it SHOULD stop the current request immediately and cancel the upload ({{upload-cancellation}}). + +* The values for `max-size` and `max-append-size` can increase without harm, they SHOULD NOT decrease as they can cause ongoing uploads to fail. +* The value for `min-append-size` SHOULD NOT increase. +* The value for `max-age` SHOULD NOT decrease enough to cause the upload resource's lifetime to end sooner. Receivers of `Upload-Limit` parse the Dictionary as described in {{Section 4.2 of STRUCTURED-FIELDS}}. Where the Dictionary is successfully parsed, this document places two additional requirements on Dictionary members. First, a member with an unknown key MUST be ignored. Second, a member with a known key but a value of unexpected type MUST cause the entire `Upload-Limit` header field to be ignored, or alternatively the complete HTTP message MUST be treated as malformed. From ee895757b11e48f96eb688b886f0d4c4472bce40 Mon Sep 17 00:00:00 2001 From: Guoye Zhang Date: Tue, 12 May 2026 11:29:54 -0700 Subject: [PATCH 3/7] Fix bad merge --- draft-ietf-httpbis-resumable-upload.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index 0dea6d2ed..5d44db7fb 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -1003,9 +1003,9 @@ Reference: * Clear up different responsibilities of server and upload resource. * Relax recommendations on client handling greater offsets. -* Clarify client behavior for 413 responses +* Clarify client behavior for 413 responses. * Remove Accept-Patch from OPTIONS responses. -* Allow upload creation requests with no content regardless of the `min-append-size` limit.. +* Allow upload creation requests with no content regardless of the `min-append-size` limit. * Allow `max-age` limit to decrease as expected. ## Since draft-ietf-httpbis-resumable-upload-10 From c1ac209b0e2e15e0edeae5d01f34ad1ecd96c18d Mon Sep 17 00:00:00 2001 From: Grant Gryczan Date: Tue, 12 May 2026 14:48:12 -0400 Subject: [PATCH 4/7] Fix grammar (run-on sentence) --- 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 5d44db7fb..9f7106bab 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -363,7 +363,7 @@ The following key-value pairs are defined: Clients usually discover limits through the `Upload-Limit` header field when the upload resource is created ({{upload-creation}}). Throughout the lifetime of the upload resource, these limits SHOULD NOT change in a way that causes failures for clients adhering to the initially discovered limits. If the client discovers that it cannot continue the upload while adhering to the limits, it SHOULD stop the current request immediately and cancel the upload ({{upload-cancellation}}). -* The values for `max-size` and `max-append-size` can increase without harm, they SHOULD NOT decrease as they can cause ongoing uploads to fail. +* Although the values for `max-size` and `max-append-size` can increase without harm, they SHOULD NOT decrease as that can cause ongoing uploads to fail. * The value for `min-append-size` SHOULD NOT increase. * The value for `max-age` SHOULD NOT decrease enough to cause the upload resource's lifetime to end sooner. From 60b65fd7bdf6ad3a819634fe06f7c7d9e2af09a1 Mon Sep 17 00:00:00 2001 From: Grant Gryczan Date: Tue, 12 May 2026 17:06:47 -0400 Subject: [PATCH 5/7] Disambiguate `max-age` lifetime recommendation --- 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 9f7106bab..da0692eb4 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -365,7 +365,7 @@ Clients usually discover limits through the `Upload-Limit` header field when the * Although the values for `max-size` and `max-append-size` can increase without harm, they SHOULD NOT decrease as that can cause ongoing uploads to fail. * The value for `min-append-size` SHOULD NOT increase. -* The value for `max-age` SHOULD NOT decrease enough to cause the upload resource's lifetime to end sooner. +* Between subsequent responses, the end of the upload resource's lifetime as implied by `max-age` SHOULD NOT decrease. Receivers of `Upload-Limit` parse the Dictionary as described in {{Section 4.2 of STRUCTURED-FIELDS}}. Where the Dictionary is successfully parsed, this document places two additional requirements on Dictionary members. First, a member with an unknown key MUST be ignored. Second, a member with a known key but a value of unexpected type MUST cause the entire `Upload-Limit` header field to be ignored, or alternatively the complete HTTP message MUST be treated as malformed. From 8ba2caaba8eff288084c59ce58991e089770c862 Mon Sep 17 00:00:00 2001 From: Grant Gryczan Date: Wed, 13 May 2026 02:56:14 -0400 Subject: [PATCH 6/7] Add lead-in Co-authored-by: Lucas Pardue --- draft-ietf-httpbis-resumable-upload.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index da0692eb4..aa94616c3 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -362,8 +362,9 @@ The following key-value pairs are defined: : Specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response. After the resource's lifetime is reached, the server might make the upload resource inaccessible and a client SHOULD NOT attempt to access the upload resource as these requests will likely fail. The value is an Integer. Clients usually discover limits through the `Upload-Limit` header field when the upload resource is created ({{upload-creation}}). Throughout the lifetime of the upload resource, these limits SHOULD NOT change in a way that causes failures for clients adhering to the initially discovered limits. If the client discovers that it cannot continue the upload while adhering to the limits, it SHOULD stop the current request immediately and cancel the upload ({{upload-cancellation}}). +The following recommendations for limit changes can minimize the risk of causing upload failures: -* Although the values for `max-size` and `max-append-size` can increase without harm, they SHOULD NOT decrease as that can cause ongoing uploads to fail. +* `max-size` and `max-append-size` SHOULD NOT decrease. * The value for `min-append-size` SHOULD NOT increase. * Between subsequent responses, the end of the upload resource's lifetime as implied by `max-age` SHOULD NOT decrease. From 84dbaa6c07fd80bbd945c3a2d8fbae5b362a539f Mon Sep 17 00:00:00 2001 From: Grant Gryczan Date: Wed, 13 May 2026 02:58:40 -0400 Subject: [PATCH 7/7] Fix formatting & missing `min-size` recommendation --- draft-ietf-httpbis-resumable-upload.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-resumable-upload.md b/draft-ietf-httpbis-resumable-upload.md index aa94616c3..b1664599e 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -362,10 +362,11 @@ The following key-value pairs are defined: : Specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response. After the resource's lifetime is reached, the server might make the upload resource inaccessible and a client SHOULD NOT attempt to access the upload resource as these requests will likely fail. The value is an Integer. Clients usually discover limits through the `Upload-Limit` header field when the upload resource is created ({{upload-creation}}). Throughout the lifetime of the upload resource, these limits SHOULD NOT change in a way that causes failures for clients adhering to the initially discovered limits. If the client discovers that it cannot continue the upload while adhering to the limits, it SHOULD stop the current request immediately and cancel the upload ({{upload-cancellation}}). + The following recommendations for limit changes can minimize the risk of causing upload failures: * `max-size` and `max-append-size` SHOULD NOT decrease. -* The value for `min-append-size` SHOULD NOT increase. +* `min-size` and `min-append-size` SHOULD NOT increase. * Between subsequent responses, the end of the upload resource's lifetime as implied by `max-age` SHOULD NOT decrease. Receivers of `Upload-Limit` parse the Dictionary as described in {{Section 4.2 of STRUCTURED-FIELDS}}. Where the Dictionary is successfully parsed, this document places two additional requirements on Dictionary members. First, a member with an unknown key MUST be ignored. Second, a member with a known key but a value of unexpected type MUST cause the entire `Upload-Limit` header field to be ignored, or alternatively the complete HTTP message MUST be treated as malformed.