Code change:
with the "201 (Created)" status code and an "Upload-Complete" header value set to false. <del> If the request includes an "Upload-Complete" field value set to true and a valid "Content-Length" header field, the client attempts to upload a fixed-length resource in one request.  In this case, the upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. </del> <ins> The request can indicate the upload's final size in two different ways.  Both indicators may be present in the same request as long as they convey the same size.  If the sizes are inconsistent, the server MUST reject the request by responding with a "400 (Bad Request)" status code. If the request includes an "Upload-Complete" field value set to true and a valid "Content-Length" header field, the client attempts to upload a fixed-length resource in one request.  In this case, the upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. The value can therefore not be used if the upload is split across multiple requests. If the request includes the "Upload-Length" header field, the server MUST record its value as the upload's final size.  A client SHOULD provide this header field if the upload length is known at the time of upload creation. The upload is not automatically completed if the offset reaches the upload's final size.  Instead, a client MUST indicate the completion of an upload through the "Upload-Complete" header field.  Indicating an upload's final size can help the server allocate necessary resources for the upload and provide early feedback if the size does not match the server's limits (upload-limit). </ins> The server MAY enforce a maximum size of an upload resource.  This <del> limit MAY be equal to the upload's final size, if "Upload-Complete: ?1" and "Content-Length" are present in the upload creation request, or an arbitrary value.  The limit's value or its existence MUST NOT change throughout the lifetime of the upload resource.  The server MAY indicate such a limit to the client by including the "Upload- Limit" header field in the informational or final response to upload </del> <ins> limit MAY be equal to the upload's final size, if available, or an arbitrary value.  The limit's value or its existence MUST NOT change throughout the lifetime of the upload resource.  The server MAY indicate such a limit to the client by including the "Upload-Limit" header field in the informational or final response to upload </ins> creation.  If the client receives an "Upload-Limit" header field indicating that the maximum size is less than the amount of bytes it intends to upload to a resource, it SHOULD stop the current upload

Related discussion:
text: As NAME mentioned in URL, is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content. Good point that a client may validate digests while a multi-request upload is progressing. A server could respond with the latest digest of the entire uploaded data (not just the data from the last request) using after POST and PATCH requests. The client can then validate and decide to abort if the digests don't match. This usage would be in line with the PATCH example in . The server responds with the digest of the representation after the PATCH has been applied. The example also notes that the server is not required to respond with the representation itself and could also have returned a 204 (as is done for resumable uploads):
Makes sense, thanks for clarifying. is most likely good enough given that it indicates the current checksum of what the server received.
NAME please, stalk me for a review in the next week :)
NAME It took me a bit more than a week, but here we go: URL Happy to hear your feedback :)