httpwg
RESUMABLE: Section 10.1 description of how to use Repr-Digest seems wrong
During WGLC review, @MikeBishop raised the following issue on https://lists.w3.org/Archives/Public/ietf-http-wg/2025JulSep/0123.html
In Section 10.1, regarding integrity verification, could Repr-Digest also be on the HEAD of the upload resource?
However, looking even further at the text I'm not 100% sure the suggested interactions are correct (and I probably should have caught this earler).
First, we state this use case which seems fine
If the client knows the integrity digest of the entire representation data before creating an upload resource, it can include the Repr-Digest header field when creating an upload (Section 4.2). Once the upload is completed, the server can compute the integrity digest of the received representation data and compare it to the provided digest. If the digests don't match, the server SHOULD consider the upload failed, not process the representation further, and signal the failure to the client. This way, the integrity of the entire representation data can be protected.
In other words, the client knew the full data and sent it over for the server to eventually use once it has all the data.
The bit I'm less sure about is
the server can compute the digest continuously during the upload and include the Repr-Digest header field in responses to upload creation (Section 4.2) and upload appending requests (Section 4.4) even when the upload is not completed yet.
If the upload is, for example, 1000 bytes of content but the server only received 500 bytes, the hash it would produce over 500 bytes is not the same as over 1000. So is this the representation of the upload resource? Does HTTP allow that to change over time (I think it does). If we agree, the text could probably be clearer on that point. Then, we can answer Mike's original point that Offset Retrieval (HEAD request) returns the state of the upload resource including a Repr-Digest.
This got me thinging about some security implications there might be wrt content negotiaton, see https://github.com/httpwg/http-extensions/issues/3213#issuecomment-3217520588
If the upload is, for example, 1000 bytes of content but the server only received 500 bytes, the hash it would produce over 500 bytes is not the same as over 1000. So is this the representation of the upload resource? Does HTTP allow that to change over time (I think it does).
That has been my interpretation so far, yes. The representation on the server-side changes during the upload as data is appended to it.
