Resumable Upload: Require client to adhere to limits in Upload-Limit

[Acconut]

Currently, the client is not required to adhere to limits announced in the Upload-Limit header field in responses. As discussed in #3006 (comment), it doesn't make a lot of sense to give the client the option to willingly ignore limits that the server announces. Hence, this PR changes the normative language to require the client to adhere to any limits that the client received and recognizes.

[guoye-zhang]

I'm hesitant about making this a MUST. Currently, our client does not parse Upload-Limit at all, as we only operate in the mode where we upgrade a traditional upload to a resumable upload. Let's suppose that the upload itself is larger than max-size, it might not be resumable but it might still be fine to continue as a traditional upload. And respecting max-append-size requires a lot of additional work on the client side since we currently only do Upload-Complete: ?1.

The server can always enforce the limits by sending a 413 Content Too Large response, or a 5xx response so the client would try to resume. I'm not sure if it's worth the additional complexity to adhere to the limits on the client side since the server has to enforce it anyway.

[LPardue]

I tend to agree with Guoye. I'd treat this as an advisory header, in the vein of Retry-After https://www.rfc-editor.org/rfc/rfc9110.html#section-10.2.3.

In fact, removing the SHOULD might be closer to reality. Instead, we can explain why clients benefit from consuming the hint and taking some action. Then we can leave it up to them to make their own call.

[Acconut]

I understand that implementing the client behavior can be challenging, especially max-append-size. My main concern is that making it optional for the client to follow limits could result in interoperability issues. Our experience with tus has been that a sizeable number of server deployments for resumable uploads enforce a maximum request content size. Usually to accommodate for restrictions in proxies or other parts of the infrastructure. I would assume that similar restrictions will exist if people deploy resumable uploads as defined in this draft.

A client that ignores Upload-Limit can then run into issues uploading files that are larger than the server's maximum request size. Proxies usually reject requests that are too large with a 413, preventing the client from resuming, causing the upload to fail. As Guoye mentioned, the upload would work if the proxy consumes request content until reaching the size limit and then responding with a 5xx. The client will resume and the upload can continue, but I'm unsure if such a proxy behavior is feasible in reality.

If a client respects the limits announced by the server, it can directly adjust to the server's restrictions and increase interoperability.

[LPardue]

I agree with these points. However, isn't that pretty much the situation we're already in today?

I know that I operate proxy servers that have variable upload limits, and variable behaviour when it comes to buffering of upload before responding vs. Responding immediately and allowing uploads to continue unbuffered (aka streamed).

The language in the Upload Limits section is currently that a server MAY not do something if the action exceeds a limit it advertised. I don't think it's acceptable to levy a MUST requirement on a client if a server might be more flexible in how it applies limits it advertised.

I know it feels like it might help to be strict but HTTP is generally quite loose. The market will decide what it wants to do. And if people are already saying "it's easier for me to deal with rejection staus codes like I do with all HTTP upload services than use Upload-Limit" the a MUST probably won't change their mind.

[Acconut]

However, isn't that pretty much the situation we're already in today?

Yes, leaving adherence to upload limits optional won't make interoperability less likely than it currently is. With this new draft we would have the opportunity to improve the chance of interoperability by learning from shortcomings in current deployments.

That being said, this PR might not have the impact that I imagine. There will likely be two kinds of clients in production environments:

• People using RUFH clients to upload to known servers (like most tus setups today). They therefore know which limits the server imposes and can configure the client accordingly in advance. Or they know that their client automatically adjusts to limits on the fly. Forcing adherence to limits won't change anything here.
• Clients that automatically upgrade traditional uploads to resumable uploads (like URLSession on iOS). They don't usually know the server limits upfront. But a server that would accept a representation transferred in one request as a traditional upload is probably just as likely to accept the same representation as a resumable upload in one request. It would be odd if the server accepts a 1GB traditional request but requires the equivalent resumable upload to be split across multiple requests. Hence, forcing adherence to limits will unlikely improve interoperability.

Considering that, I am also fine with leaving the SHOULD as is.

I don't think it's acceptable to levy a MUST requirement on a client if a server might be more flexible in how it applies limits it advertised.

Fair point. We could consider making the limits more strict on the server-side. But then again, I consider the limits as hints from the server to client about what it will likely be able to handle, not as an enforceable contract.