RESUMABLE: Unclear how server should handle completing request with insufficient length

[GrantGryczan]

If the client sends an upload creation or append request with Upload-Complete: ?1 whose content isn't large enough to meet the upload length expected by the server, what should the server do? I don't think this edge case is ever explicitly commented on in the draft. If it is, I can't find it.

Some options I can think of:

1. Mark the upload as completed, process the content, and adjust the upload length accordingly. (Can the upload length change? Opened RESUMABLE: Unclear if changing upload length is allowed #3431)
2. Don't mark the upload as completed, but respond with success, and otherwise process the content as if there's no issue.
3. Don't mark the upload as completed, and respond with an error, but otherwise process the content as if there's no issue.
4. Don't mark the upload as completed, respond with an error, and don't comment on whether the content should be processed.
5. Don't mark the upload as completed, respond with an error, and recommend against processing the content.

I personally would suggest either option 4 or 5.

[smatsson]

I agree with you and would propose option 5 here as this is clearly a client error given how the current spec is written. The server should not process this content as it's not completely uploaded.

Food for thought though: should Upload-Length be treated as an exact value (as currently specified) or as a maximum? If the latter is allowed this case wouldn't be an error. The client estimated 100 bytes but it turned out to be 90 and that seems reasonable to handle gracefully. The current wording does create some inconsistency: if Upload-Complete is what finalizes the upload then Upload-Length being an exact value is somewhat redundant in the completing request (unless we want to support a zero-byte finalizing request for some reason, e.g. making sure that the last response is received).

[Acconut]

The situation we have is comparable to HTTP/2. The request body is transmitted as one or many DATA frames where the final frame has the END_STREAM flag set. The request header can optionally contain the Content-Length header, but RFC 9113 clearly says that a request is malformed if the value from the header doesn't match the amount from the DATA frames (https://www.rfc-editor.org/rfc/rfc9113.html#section-8.1.1-2):

A request or response is also malformed if the value of a content-length header field does not equal the sum of the DATA frame payload lengths that form the content, unless the message is defined as having no content.

The Content-Length header in HTTP/2 is not used for message delimitation as in HTTP/1.1, but to indicate the content length to the receiver.

That's how I see Upload-Length as well. It's a signal how much data the client will send, but it's not responsible for upload termination. Any inconsistency between Upload-Length and the actual data amount should render the upload invalid. The upload length is not a vague signal, but a value that server can rely on if the client decides to set it.

[Acconut]

Thinking more about this, the situation is the same as in #3431: the client first indicates the length via Upload-Length, but then provides a different (smaller) value using Upload-Complete: ?1 + Content-Length + Upload-Offset. And the spec already disallows this as mentioned in #3431 (comment). I think we can close this one as well.

[GrantGryczan]

Maybe. Currently, the draft doesn't list Upload-Offset as tying into the indication for the upload length. I think that would need to be added for this issue to be resolved that way.

[Acconut]

The text does take the offset into consideration:

If the request includes the Upload-Complete field value set to true and a valid Content-Length header field, the request content is the remaining representation data. The length is then the sum of the current offset (Section 4.1.1) and the Content-Length header field value.

(https://www.ietf.org/archive/id/draft-ietf-httpbis-resumable-upload-11.html#section-4.1.3-3.1.1)

The only loophole is that this is only specified for requests with Content-Length. This header isn't always present (e.g. when Transfer-Encoding: chunked is used), so this case isn't prohibited at the moment:

1. Empty POST request with Upload-Length: 1000 and Upload-Complete: ?0
2. PATCH request with Upload-Complete: ?1, no Content-Length, but 500 bytes of content

[GrantGryczan]

Ah, good catch! That can easily be mended.