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: 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.