Original text:
MUST NOT fail the parsing to facilitate the addition of new limits in the future.  8.3. The "Upload-Complete" request and response header field indicates

Reviewer comments:
This change allows client to discover support for resumable uploads and potential limits via an OPTIONS request. Closes URL A brief comment on this sentence: Once the server has created an upload resource it might have more information available (user details, file metadata etc) and apply different limits than it would have known upfront for an OPTIONS request where this information was not available. We allow this difference but recommend that the upfront announced limits are not looser than the limits after the upload resource has been created. The client can then assume that it can create an upload resource if it obeys to the upfront announced limits even if looser limits will then apply later. Does this make sense? Or is this addition rather unnecessary?
Is OPTIONS a required feature on the server side? What about requests?
Yes, I think a server should be required to support this. If it only wants to provide resumable uploads for specific users, it does not have to announce this for unauthorized users. If a server supports resumable uploads for all target URIs, then it should respond with to an request. But I am unsure how often this actually happens.
introduced for the server to indicate limits on the upload resource (e.g. maximum size). These limits are announced to the client during upload creation in the informational or final responses. However, the client cannot discover these limits without attempting to create an upload resource. A client may want to avoid creating an upload resource if it knows the the server limits cannot be satisfied. A possible solution is to allow clients to send an OPTIONS request upfront to the URL from upload creation. The server might then include the Upload-Limit header in its response, so that the client knows them before trying to create an upload resource. However, a client is not required to send this OPTIONS request upfront. This would also be handy in a possible future where browsers natively implement resumable uploads. The response for a CORS preflight request might then already include information whether the endpoints supports resumable uploads and, if so, under which constraints. The browser can use this data to optimize the uploads.
Early thought: Would it be beneficial to include some kind of marker that this endpoints supports resumable upload in the OPTIONS response? For client's that does not support upgrading requests (e.g. due to lack of support for 1xx responses) who whishes to know upfront if the upload can be split (Upload-Complete: ?0) or if a regular upload (without resumability) should be performed.
Interesting idea! The presence of the Upload-Limit header could be used as an indicator for support of resumable uploads. In theory, its value can be an empty dictionary as well if the server does not impose any limits. If the response does not include the Upload-Limit header, the client can either attempt an upgradable upload or directly fall back to regular uploads.
URL
Too bad we can't use the empty dictionary header as an indicator. It's probably an edge case anyway that a client, not knowing the support of the server, would issue an OPTIONS request to find out? Or maybe not, given CORS? What do others think?
Thanks for the pointer, Lucas! If we cannot use an empty value, a server could also fill in a dummy value, e.g. . This is only necessary if the server does not apply any limit at all (not even ), which I suppose is very rare in reality. In general, the situation where a client wants to know upfront whether the server supports resumable uploads appears like an edge case to me. I assume the client will often know that the server supports it or otherwise will attempt to transparently upgrade a traditional upload into a resumable one. So I don't think we have to spend too much energy on this. How do you feel about this, Stefan?
NAME Yeah I think that is fair enough. The use cases where a generic client (without prior knowledge of server support nor support for informational responses) would send an extra OPTIONS request seems slim to none. The CORS example is interesting but mostly (always?) happens in a browser which does support informational responses and thus would use the 104.
Opened URL for this.

Revised text:
MUST NOT fail the parsing to facilitate the addition of new limits in the future. <ins> A server that supports the creation of a resumable upload resource (upload-creation) under a target URI MUST include the "Upload-Limit" header field with the corresponding limits in a response to an "OPTIONS" request sent to this target URI.  If a server supports the creation of upload resources for any target URI, it MUST include the "Upload-Limit" header field with the corresponding limits in a response to an "OPTIONS" request with the "*" target.  The limits announced in an "OPTIONS" response SHOULD NOT be less restrictive than the limits applied to an upload once the upload resource has been created.  If the server does not apply any limits, it MUST use "min-size=0" instead of an empty header value.  A client can use an "OPTIONS" request to discover support for resumable uploads and potential limits before creating an upload resource. </ins> 8.3. The "Upload-Complete" request and response header field indicates