Original text:
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>  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>  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

Reviewer comments:
Closes URL A client can express its interest in digests using during upload creation. The server can then respond with after POST and PATCH requests to share its digest with the client. The client computes its digest as well during the upload and compares the digest to spot issues. The representation digest of an upload resource covers the entire bytes that have been uploaded so far (i.e. right until the upload offset). NAME NAME Is this in line with the semantics of RFC 9530?
NAME Need a week for the review :)
Preliminary feedback: I'd simplify the language/split text on multiple lines; Describe processing in separate subsections, e.g.
Thank you for the feedback, Roberto. I added subsections for representation and content digests in URL I think this division helps the reader and also makes sense since representation digests can cover the entire upload, while content digests only cover one request. Let me know if you think differently.
URL added some guidelines on how a client may include integrity fields to upload requests for protecting the integrity of a single request or the entire upload. However, this either requires the client to compute the digest upfront (before sending a request or starting the upload), or the use of request trailers, which is not very widespread and not always possible (e.g. the ). Instead of requiring the client to compute the digest upfront, the server and client could calculate the digests while the upload is ongoing. Once the upload is completed, the server can send its digest to the client in the response to the request that completed the upload. The client can then compare the server's digest to its computed value. If they don't match, it can raise an error to the end user and decide to not continue using the uploaded data. The client should indicate its interest in the server's digest when an upload is created, so the server is not required to compute the digest if the client has no interest. I am wondering if the from can be used for this. Can a client include in the first upload creation request, but the server delivers the digest potentially later in a response for a subsequent request? An upload may be spread across multiple requests.
Should also be supported? For multi request uploads, there's really no use to continue if request 3 of 100 got corrupted.
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 :)

Revised text:
with the "201 (Created)" status code and an "Upload-Complete" header value set to false.  <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  <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