Code change:
MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Incomplete" header set to true. <ins> If the request includes the "Upload-Complete: ?1" header field and a valid "Content-Length" header field, the client attempts to upload the remaining resource in one request.  In this case, the upload's final size is the sum of the upload's offset and the "Content-Length" header field.  If the server does not have a record of the upload's final size from the Upload Creation or previous Upload Appending Procedures, the server MUST record the upload's final size to ensure its consistency with future Upload Appending Procedures.  If the server does have a previous record, the upload's final size from a previous procedure MUST match the upload's final size from the current Upload Appending Procedure.  If they do not match, the server MUST reject the request with the "400 (Bad Request)" status code. </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD

Related discussion:
text: Based on this information, the server can determine if an upload is complete or not without relying on . Adding to the upload logic would mean that we have two indicators for upload completeness, which could potentially disagree with each other. Personally, I think we should not use to determine the upload's completeness and only determine it based on whether the client set in a successful request. For each Upload Creation Procedure or Upload Appending Procedure, the should be set to the number of bytes that the client wants to send in this individual procedure. For example, if you want to transmit 100 bytes in the first POST request, set (or not if you use ). If you want to transmit 200 bytes in the following PATCH request, set . If you want to finish the upload then, set and the upload is considered complete with its 300 bytes of content.
The issue in NIOResumableUpload was a bug, not how this is supposed to work. Offset + Content-Length = final upload size when the upload is complete, and if the client has told the server about the final size, it shouldn't be allowed to change its mind.
Echoing what Guoye said, should not determine the upload's completeness, but if an request has a , then the server can expect and enforce the final upload size based on that . This prevents a client from appending more bytes to their upload than the server anticipated. Ex. Client starts an upload , Server expects a final upload size of 100 bytes Upload is interrupted, offset-retrieving, server sends Client now tries to append an extra ~10GB Client sends , , Server can reject this request
I see, thanks for the explanation. That makes sense. Basically, in conjunction with let the server know the final upload size, which should not be changed
How does that work if the last append has in conjunction with . The Content-Length needs to match the number of bytes in the append message.
Final size = upload-offset + content-length if the upload is complete
So the first ever request with Upload-Incomplete: ?0 and content-length sets the expected final size. Every other request must have a content-length less than that value?
Yeah, once the final length is determined, it cannot be changed by subsequent requests.
OK I think that makes sense but it's not obvious from the spec. We should try and make it more accessible with some new or different text.