Code change:
failed and not process the uploaded data further.  This way, the integrity of the entire uploaded data can be protected. <ins> Alternatively, when creating an upload (upload-creation), the client MAY ask the server to compute and return the integrity digests using a "Want-Repr-Digest" field conveying the preferred algorithms.  The response SHOULD include at least one of the requested digests, but MAY not include it.  The server SHOULD compute the representation digests using the preferred algorithms once the upload is complete and include the corresponding "Repr-Digest" header field in the response.  Alternatively, the server MAY compute the digest continuously during the upload and include the "Repr-Digest" header field in responses to upload creation (upload-creation) and upload appending requests (upload-appending) even when the upload is not completed yet.  This allows the client to simultaneously compute the digest of the transmitted upload data, compare its digest to the server's digest, and spot data integrity issues.  If an upload is spread across multiple requests, data integrity issues can be found even before the upload is fully completed. 15.2. Content digests help verify the integrity of the content in an individual request. </ins> If the client knows the integrity digest of the content from an upload creation (upload-creation) or upload appending (upload- appending) request, it MAY include the "Content-Digest" header field

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.