Indicating general and resource-specific upload limits

[Acconut]

The current draft for resumable uploads does not include methods for exchanging upload limits. Exposing the limits from the client and server-side could be helpful in a few cases:

1) Indicating the upload length

When starting an upload, the client may indicate the full upload size to the server by including the content-length and upload-complete: ?1 header fields in the upload creation request. In this case, the server knows that content-length is the full upload size. If the request cannot be completed and the client resumes the upload, not more data than specified in the initial content-length should be accepted by the upload resource.

However, the client might not set upload-complete: ?1 because it intends to split the upload accross multiple requests. This might happen because the server imposes an upper limit on the request body size (for example, requests for resumable uploads for CloudFlare may not be larger than 200 MB.

In these cases, it would be helpful for the server if the client could indicate the full upload length in the upload creation even if it does not plan on transmitting the entire file in a single request.

That being said, we would have to define how an upload length indication interacts with upload-complete: ?1 and which value takes precedence if they contradict each other.

2) Indicating the server's upload limit

A client might want to obtain the server's upper limit before starting the file transmission. If the file to be transferred exceeds this limit, the client can decide to not start the upload transfer at all and avoid performing the upload attempt which would likely fail at some point when the server's limit is exhausted.

Potential solutions could be:

• Sending an OPTIONS request before creating an upload resource. The server can include its upper limit in the response.
• Once an upload resource is created, the server includes its upper limit in an informational response. Depending on this value, the client might decide to start or cancel the upload transmission.

Are these two use cases we should address in the draft?

[smatsson]

1. Indicating the upload length

I don't have a perfect solution to this but FWIW tus uses Upload-Length to indicate this value.

2. Indicating the server's upload limit

From experience with tusdotnet I know there have been questions on how to have a dynamic max size per other things than the path e.g. using the request content-type or similar (audio having one max size, video another). This isn't possible when using an OPTIONS request (as the server does not know the content-type that will be uploaded) so I would prefer to see the max size included in the informational response and the response to the creation procedure. If the client receives the max size in the informational response it can cancel the upload directly and for clients not supporting informational responses the can just not upload any data, after they receive the upload url, if they know that the data is too large. EDIT: Also if we include a way to indicate the complete upload size the server can just reject the creation procedure without the client having to do anything.

[Acconut]

I opened #2747 to communicate resource-specific upload limits.