resumable: clarify greater offset

[mertalev]

Resolves #3268, making it more explicit that the resource offset is allowed to be greater than what the client sent in its current upload. It also consolidates the rejection behavior for lesser and greater offsets.

[Acconut]

Thank you proposing this text. However, I think that this paragraph is a bit too ambiguous about how clients react to suddenly increasing offsets? Are they expected to follow the offset (i.e. MUST)? Are they recommended to do so (i.e. SHOULD)? Can they decide what to do?

The current text allows clients to abort of offset jumps, but doesn't require this behavior. A client that follows offset jumps would still be compliant with the current text. From that perspective it seems like this PR doesn't change much in the end yet.

[mertalev]

The intent is that they have to jump to the provided offset to continue the upload, or else the upload is a failure. I can see how that's a bit ambiguous in the text. My thought would be to make it a MUST to follow the jump since the server is the source of truth for the current offset. Does that seem reasonable?

[Acconut]

If the intention is to require clients to follow offset jump, then MUST should be used in my opinion.

That being said, I want to discuss this topic at the upcoming httpbis meeting on Wednesday and collect opinions. The draft assumes that there's only one client uploading to a given upload resource and mandatory support for offset jumps is a deviation from this assumption.

[guoye-zhang]

There are cases where jumping ahead doesn't make sense, e.g. uploading a continuous video stream.

This is targeting a specific use case where the client crashed and forgot about the resume URL, the server could look up the resume URL based on the creation request to recover the in-progress upload. The main question is whether this is a failure mode in scope for the spec.

[Acconut]

This is targeting a specific use case where the client crashed and forgot about the resume URL, [..]

Or in cases where the client never learned the upload resource URL in the first place because it didn't receive the interim or final response for the upload creation request. If the client is aware of the server's support for resumable upload and includes an application-specific header to deduplicate uploads (e.g. an idempotency key or hash), this could allow the client to re-send the upload creation request while being redirected to the previously created upload resource. From there it can then continue the upload. That was also my reasoning behind opening #2293 some time ago.

To make this work, we don't have to include details on which headers can be used to deduplicate uploads. That's up to the application. But we need a client that can follow an offset jump, which most clients likely have to implement anyways. If a client wants to resume an upload from a previous session, it has to seek to the correct offset anyways after discovering it via a HEAD requests. So it wouldn't be too much additional implementation work.

That being said, I'm unsure if this has to be mandatory for clients or optional as it currently is.

[mertalev]

The main issue with making the jump optional is that the server won't know whether the client implemented this, so will have to consider both possibilities or risk interop issues.

[mertalev]

I tried to clarify the client behavior here, let me know how you feel about the wording!