httpwg
RESUMABLE: use of 204 (No Content) is surprising wrt HEAD
During WGLC review, @MikeBishop raised the following issue on https://lists.w3.org/Archives/Public/ietf-http-wg/2025JulSep/0123.html
The use of 204 (No Content) surprises me, because the upload resource inherently does have content -- the bytes uploaded so far. The response to a HEAD request is supposed to be identical to what GET would have returned, except with no content. Presumably a GET to this resource would return a 200, not a 204, and the uploaded bytes? Given that this is a HEAD request, the body would not be transferred even on a 200, so that would seem the more natural response code.
Whether the upload resource can be GET, or not, is something @gstrauss also mentioned over on https://github.com/httpwg/http-extensions/issues/3188#issuecomment-3184237779
This ticket might be a better place to continue the wider discussion. If so, we can re-title the ticket, let us know.
https://github.com/httpwg/http-extensions/issues/3228 (question about repr digest) also got me thinking, can an offset retrival request do content negotiation? The reason to ask this is because if the client sent different Accept-Encoding values, the server needs to make a selected representation (even if it doesn't transmit any bytes), which is encoding-aware and would need to respond with different Repr-Digests.
If we would allow GET on an upload resource, then content negotiation seems like something that should be supported. Even without GET, asking a server to do work such as gzip a partial upload is something security considerations probably need to address.
Another option could be to consider that the resource is only created but not retrievable (even partially) until complete, and that any non-upload request to it would be idempotent and only return 201 Created with Location and upload offset. I think that this would be a better for real-world implementations where servers might store contents into a quarantine location until it can be analyzed. It's unlikely that applications are interested in letting clients upload partial contents and retrieve them, because that could easily be abused to constitute uncontrolled file exchanges on data that cannot be inspected for malware for example.
201 Created with Location doesn't seem applicable here, at least not for the request resource. Nothing was created, and the location would be the URL the client just requested. For the base resource, maybe, if it was a PUT rather than a POST/QUERY, and there's an expectation that a resource is in the process of being created at that URI.
I'm okay with not supporting GET, but it would be odd to allow HEAD to succeed and GET to fail, given HEAD's definition. We already recommend to tightly constrain access to the upload resource so only the client that created it can get to it. That said, you're right to point out the potential abuse of uploading something "partial", not marking it complete, and then passing the URL of the upload resource along with the appropriate token to another client to retrieve.
