Code change:
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

Related discussion:
text: 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.