httpwg
RESUMABLE: it might be reasonable for the client to require that the offset be no less than the last 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.3.1, it might be reasonable for the client to require that the offset be no less than the last Upload-Offset that it received in interim responses during the previous upload. After all, we already said the client can discard that data.
This is an excellent point. Another reason I'm seeing is to limit the abilities for abusive clients to waste bandwidth by constantly uploading the same partial content. However we should at least permit to restart from scratch because in certain cases it's likely that it would be much easier for the client to process the whole file at once again than to seek in it (e.g. if a local proxy needs to inspect the content and that content is compressed). What is not desirable is a restart from a non-null offset lower than the upload-offset.
That's a good point, but why wouldn't such a client simply DELETE the upload resource and then reattempt the upload? I think the spec already covers that by telling servers to reject requests which don't start at the current offset.
Regardless, my point in this issue isn't about server policing of the client's Upload-Offset value, but about clients requiring that the server never move backward in the amount of data it claims to have successfully processed. If we're saying clients can discard data once the server has confirmed it's got it, then clients have to be able to rely on the goalposts not moving, as it were.
