Resumable Upload: Requesting digests from server

[Acconut]

Problem

#2748 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 Fetch API does not support it currently).

Possible solution

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 Want-Repr-Digest from RFC 9530 can be used for this. Can a client include Want-Repr-Digest 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.

[smatsson]

Should Want-Content-Digest also be supported? For multi request uploads, there's really no use to continue if request 3 of 100 got corrupted.

[Acconut]

As @LPardue mentioned in #2748 (comment), Want-Content-Digest is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content.

For multi request uploads, there's really no use to continue if request 3 of 100 got corrupted.

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 Repr-Digest 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 section B.9. of RFC 9530. 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):

Note that a 204 No Content response without content, but with the same Repr-Digest field-value, would have been legitimate too.

[smatsson]

Makes sense, thanks for clarifying. Repr-Digest is most likely good enough given that it indicates the current checksum of what the server received.

[ioggstream]

@Acconut please, stalk me for a review in the next week :)