httpwg
RESUMABLE: In 4.4.3, little suprised 204 response doesn't also include Upload-Offset
During WGLC review, @MikeBishop raised the following issue on https://lists.w3.org/Archives/Public/ietf-http-wg/2025JulSep/0123.html
In 4.4.3, while the client can correctly infer that the offset is now 200, I'm a little surprised that the 204 response doesn't also include Upload-Offset: 200.
Note that I changed the byte values of uploads and offsets in other PRs, but the comment remains - should the 204 return an offset?
The requirement was dropped between draft 5 and 6
Require Upload-Complete, but not Upload-Offset or Upload-Limit, for append responses.¶
It might be useful for debugging, but doesn't affect the functionality of the protocol.
Proposal: close with no action.
There are various permutations of including or omitting optional/helpful fields that are not mandatory. I'm not a fan of "implementing via example" and don't feel enthusiastic about adding more examples to reflect the optionality of these fields.
As Guoye mentioned, we removed Upload-Offset from append responses because it's not needed to perform an upload and resume. I wonder if we have to revisit that assessment when considering servers enforcing granularities, as discussed in https://github.com/httpwg/http-extensions/issues/3193. Servers might discard trailing bytes to fit certain append granularities, in which case it would be helpful to signal back to the client how many bytes were actually appended. If not, clients will discover the actual offset when trying to append the next data, which then fails with a 409 Conflict. However, that additional request could be avoided if responses include Upload-Offset. Not sure if we want to go that route.
Are there other reasons where the server might not have saved all the bytes sent while still not breaking down completely, a.k.a where the client can continue the upload with a new upload offset? As Marius wrote, it might be a simple fix to include the Upload-Offset in the append response and have the client verify that it matches what is expected, otherwise use the value in the Upload-Offset header (or do a new retrieval of it)
Are there other reasons where the server might not have saved all the bytes sent while still not breaking down completely, a.k.a where the client can continue the upload with a new upload offset?
No other than #3193 that I can think of.