resumable: Upload-Limit language is ambiguous

[danielresnick]

Spinning off from #3193 (comment)

The spec as is (draft 10) is unclear on whether clients MUST respect limits a server sends down via a Upload-Limit header.

"The client SHOULD respect any limits (Section 4.1.4) announced in the Upload-Limit header field in interim or final responses" -> implies optional but strongly recommended

"max-append-size: Specifies a maximum size counted in bytes for the request content in a single upload append request (Section 4.4). The server might reject requests exceeding this limit. A client that is aware of this limit MUST NOT send larger upload append requests. The value is an Integer." -> implies clients are required to respect this limit (since why wouldn't they be "aware" of it? It's included in the spec, and clients are guaranteed to have received it in the Upload Creation response if the server sets it).

Overall I'd be keen to make as clear as possible that it's (at least) strongly recommended that clients which intend to be maximally interoperable with a variety of servers respect all known Upload-Limits.

I'm happy to take a stab at rewording to try to remove this ambiguity if helpful, but lets first align on the desired end state.

[Acconut]

Thank you for the feedback! I can understand that this language is not very clear.

"The client SHOULD respect any limits (Section 4.1.4) announced in the Upload-Limit header field in interim or final responses" -> implies optional but strongly recommended

IIRC, the intention behind SHOULD is that in some cases the client does not know the limit before starting to transfer data. For example, if the upload creation request carries representation data, the client starts sending this data before it receives the limits. Hence it's not able to know what the resources's max-size, min-append-size and max-append-size limits are.

That being said, by the time the first append request is started, the client should have had the opportunity to discover the limits. Either through the upload creation response or a HEAD response.

[danielresnick]

That interpretation sounds reasonable to me though I think @guoye-zhang had a different one (see #3193 (comment)). @guoye-zhang do you think it's realistic and not too onerous for clients like UrlSession to support limits after optimistic upload creation?

[guoye-zhang]

I think it would be possible to support, but we cannot comment on future plans. I have the feedbacks you filed, and if you have official channels to escalate this through the management chain, it would definitely help us prioritizing the work.

[danielresnick]

Thanks that makes sense, mostly just looking for signal on whether you have strong feelings about what direction the spec goes here as an owner of a key client impl

[guoye-zhang]

Implementing Upload-Limit support will definitely add additional work and complexity, but enabling more interop is more important.

On the topic of interop, maybe we need an explicit signal that the client supports certain limits, e.g. a request header Upload-Limit-Supported: min-append-size, max-append-size, append-granularity. The server could be more confident sending a 409 to reject the upload creation and get a compliant append. (We don't need to include it in the current spec to delay it further, but can do it as an experiment for a future extension)