Require that upload offset does not decrease over time

[Acconut]

#2664 added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes Upload-Offset: 100 and the next includes Upload-Offset: 50.

For now, this requirement is not mentioned for responses to offset retrieval responses. As @guoye-zhang mentioned in #2664 (comment), we should add this rule there as well.

Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).

[guoye-zhang]

Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.

[Acconut]

A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0.

I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that.

That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.