Requires Accept-Patch in OPTIONS (#3242)

Partially resolves #3175

---------

Co-authored-by: Lucas Pardue <[email protected]>

Author: guoye-zhang

draft-ietf-httpbis-resumable-upload.md

@@ -353,9 +353,9 @@ Except for the `max-age` limit, the existence of a limit or its value MUST NOT c
 
 Receivers of `Upload-Limit` parse the Dictionary as described in {{Section 4.2 of STRUCTURED-FIELDS}}. Where the Dictionary is successfully parsed, this document places two additional requirements on Dictionary members. First, a member with an unknown key MUST be ignored. Second, a member with a known key but a value of unexpected type MUST cause the entire `Upload-Limit` header field to be ignored, or alternatively the complete HTTP message MUST be treated as malformed.
 
-A server that supports the creation of a resumable upload resource ({{upload-creation}}) for 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 SHOULD include the `Upload-Limit` header field with the corresponding limits in a response to an `OPTIONS` request with the `*` target unless the server is not capable of handling `OPTIONS *` requests. If the server does not apply any limits, it MUST use `min-size=0` instead of an empty header value.
+A server that supports the creation of a resumable upload resource ({{upload-creation}}) for a target URI MUST include the `Accept-Patch` ({{Section 3.1 of PATCH}}) header field in response to an `OPTIONS` request for the target URI. If a server supports the creation of upload resources for any target URI, it SHOULD include the `Accept-Patch` header field in response to an `OPTIONS` request for the target `*` (if this target is supported). The value of the `Accept-Patch` header field MUST include the full `application/partial-upload` media type, even if it already contains `*/*` or `application/*`. The `Upload-Limit` header field SHOULD be included in the response to an `OPTIONS` request if limits apply.
 
-A client can use an `OPTIONS` request to discover support for resumable uploads and potential limits before creating an upload resource. To reduce the likelihood of failing requests, 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, unless the request to create an upload resource included additional information that warrants different limits. For example, a server might announce a general maximum size limit of 1GB, but reduce it to 100MB when the media type indicates an image.
+A client can use an `OPTIONS` request to discover support for resumable uploads and potential limits before creating an upload resource. While the values `*/*` and `application/*` in the `Accept-Patch` response header field indicate the acceptance of the `application/partial-upload` in PATCH requests, it does not necessarily indicate support for all aspects of resumable uploads as defined in this document. To reduce the likelihood of failing requests, 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, unless the request to create an upload resource included additional information that warrants different limits. For example, a server might announce a general maximum size limit of 1GB, but reduce it to 100MB when the media type indicates an image.
 
 Servers, including intermediaries, can (and often do) apply restrictions on the size of individual request message content. There is no standard mechanism to communicate such existing size restriction. A server that implements one can respond with a 413 Content Too Large status code; see {{Section 15.5.14 of HTTP}}. Appending to an upload resource, as a series of appends, can be used to upload data up to the `max-size` limit without encountering per-message limits. The `min-append-size` and `max-append-size` limits apply to the upload resource. Servers might apply restrictions that are smaller than the append limits, which would also result in a failed request. Clients could deal with such situations by retrying an upload append using a smaller size, as long as the new size resides between `min-append-size` and `max-append-size`. Cases where an append uses `min-append-size` yet fails with a 413 Content Too Large response might indicate a deployment mismatch that cannot be recovered from.
 
@@ -972,7 +972,7 @@ Reference:
 ## Since draft-ietf-httpbis-resumable-upload-09
 {:numbered="false"}
 
-None yet
+* Requires Accept-Patch in OPTIONS
 
 ## Since draft-ietf-httpbis-resumable-upload-08
 {:numbered="false"}