Skip to content

Commit

Permalink
Corrections from @smatsson
Browse files Browse the repository at this point in the history
  • Loading branch information
Acconut committed Feb 19, 2025
1 parent 7849aae commit 50b4efb
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions draft-ietf-httpbis-resumable-upload.md
Original file line number Diff line number Diff line change
Expand Up @@ -375,7 +375,7 @@ Upload-Limit: max-size=1000000000

### Client Behavior

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. Opon 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.
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. 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 MAY cancel the upload ({{upload-cancellation}}) after rejecting the offset.

Expand Down Expand Up @@ -412,7 +412,7 @@ Cache-Control: no-store

### Client Behavior

A client can continue the upload and append representation data by sending a `PATCH` reqeust with the `application/partial-upload` media type to the upload resource. The request content is the representation data to append.
A client can continue the upload and append representation data by sending a `PATCH` request with the `application/partial-upload` media type to the upload resource. The request content is the representation data to append.

The client MUST indicate the offset of the request content inside the representation data by including the `Upload-Offset` request header field. To ensure that the upload resource will accept request, the offset SHOULD be taken from an immediate previous response for retrieving the offset ({{offset-retrieving}}) or appending representation data ({{upload-appending}}).

Expand All @@ -432,7 +432,7 @@ If the `Upload-Offset` request header field value does not match the current off

If the upload is already complete ({{upload-complete}}), the server MUST NOT modify the upload resource and MUST reject the request. The server MAY use the problem type {{PROBLEM}} of "https://iana.org/assignments/http-problem-types#completed-upload" in the response ({{completed-upload}}).

If the `Upload-Complete` request header field is set to true, the client intents to transfer the remaining representation data in one request. If the request content was fully received, the upload is marked as complete and the resource targeted by the initial upload creation proceeds to process the entire representation and generate a response (see {{upload-creation}}). Its response MUST include the final offset in the `Upload-Complete` header field.
If the `Upload-Complete` request header field is set to true, the client intents to transfer the remaining representation data in one request. If the request content was fully received, the upload is marked as complete and the resource targeted by the initial upload creation proceeds to process the entire representation and generate a response (see {{upload-creation}}). Its response MUST include the final offset in the `Upload-Offset` header field.

If the `Upload-Complete` request header field is set to false, the client intents to transfer the remaining representation over multiple requests. If the request content was fully received, the upload resource MUST acknowledge the new upload state by sending a response with the `201 (Created)` status code. The response MUST include the offset in the `Upload-Offset` response header field and the `Upload-Complete` response header field set to false. The response SHOULD include the `Upload-Limit` header field with the corresponding limits if existing.

Expand Down

0 comments on commit 50b4efb

Please sign in to comment.