From 6e92175a1e33d3c837800aacfac39ea88c2324db Mon Sep 17 00:00:00 2001 From: mertalev <101130780+mertalev@users.noreply.github.com> Date: Sun, 26 Oct 2025 14:07:44 -0400 Subject: [PATCH 1/2] allow greater offset --- 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 4d140d1444..b4d70e8b5e 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -502,7 +502,7 @@ HTTP/1.1 405 Method Not Allowed If the client wants to resume the upload after an interruption, it has to know the amount of representation data received by the upload resource so far. It can fetch the offset by sending a `HEAD` request to the upload resource. Upon a successful response, the client can continue the upload by appending representation data ({{upload-appending}}) starting at the offset indicated by the `Upload-Offset` response header field. -The offset can be less than or equal to the number of bytes of representation data that the client has already sent. The client MAY reject an offset which is greater than the number of bytes it has already sent during this upload by not continuing the upload and canceling the upload resource ({{upload-cancellation}}). The client is expected to handle backtracking of a reasonable length. If the offset is invalid for this upload, or if the client cannot backtrack to the offset and reproduce the same representation data it has already sent, the upload MUST be considered a failure. The client then MUST NOT continue the upload and SHOULD cancel the upload ({{upload-cancellation}}). +The offset can be less than or equal to the total length of the representation data. If the offset is greater than the number of bytes the client has already sent during this upload, it can indicate that other upload sessions have successfully appended to the resource. The client is expected to handle backtracking of a reasonable length. If the offset is invalid for this upload, or if the client cannot reproduce the representation data for the received offset, the upload MUST be considered a failure. The client then MUST NOT continue the upload and SHOULD cancel the upload ({{upload-cancellation}}). The client MUST NOT perform offset retrieval while creation ({{upload-creation}}) or appending ({{upload-appending}}) is in progress as this can cause the previous request to be terminated by the server as described in {{concurrency}}. From aedcc4cb67ee1e9c97f17c014c8fbc298c662aae Mon Sep 17 00:00:00 2001 From: mertalev <101130780+mertalev@users.noreply.github.com> Date: Mon, 10 Nov 2025 12:20:25 -0500 Subject: [PATCH 2/2] clarify jump --- 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 b4d70e8b5e..76564792ed 100644 --- a/draft-ietf-httpbis-resumable-upload.md +++ b/draft-ietf-httpbis-resumable-upload.md @@ -502,7 +502,7 @@ HTTP/1.1 405 Method Not Allowed If the client wants to resume the upload after an interruption, it has to know the amount of representation data received by the upload resource so far. It can fetch the offset by sending a `HEAD` request to the upload resource. Upon a successful response, the client can continue the upload by appending representation data ({{upload-appending}}) starting at the offset indicated by the `Upload-Offset` response header field. -The offset can be less than or equal to the total length of the representation data. If the offset is greater than the number of bytes the client has already sent during this upload, it can indicate that other upload sessions have successfully appended to the resource. The client is expected to handle backtracking of a reasonable length. If the offset is invalid for this upload, or if the client cannot reproduce the representation data for the received offset, the upload MUST be considered a failure. The client then MUST NOT continue the upload and SHOULD cancel the upload ({{upload-cancellation}}). +The offset can be less than or equal to the total length of the representation data. If the offset is valid and greater than the number of bytes the client has already sent during this upload, which can indicate that other upload sessions have successfully appended to the resource, the client MUST seek to the provided offset of the representation data before continuing the upload. The client is expected to handle backtracking of a reasonable length. If the offset is invalid for this upload, or if the client cannot reproduce the representation data at the received offset, the upload MUST be considered a failure. The client then MUST NOT continue the upload and SHOULD cancel the upload ({{upload-cancellation}}). The client MUST NOT perform offset retrieval while creation ({{upload-creation}}) or appending ({{upload-appending}}) is in progress as this can cause the previous request to be terminated by the server as described in {{concurrency}}.