[221] OPTIONS メソッドは、対象資源の通信オプションについて問い合わせるものです。

仕様書

意味

[207] OPTIONS メソッドは、 起源鯖においてあるいは中間器においての対象資源についての通信オプションに関する情報を要求するものです >>206。

[208] これを使ってクライアントは資源に関連付けられたオプションや要件や、鯖の能力について、 資源の動作を伴わずに判定することができます >>206。

構文

[209] 要求対象が * の場合、特定の資源ではなく、 鯖一般に対して適用することを表します >>206。

[210] ただし普通は鯖の通信オプションは資源に依存するものですから、 「ping」や「no-op」のようなもの、例えば HTTP/1.1 に適合するかどうかの試験などにしか有用ではありません >>206。

[211] 要求対象がそれ以外の場合、当該対象資源と通信する場合のオプションに適用することを表します >>206。

[215] クライアントは、要求鎖上の特定の受信者を対象とすべく Max-Forwards: ヘッダーを送信することができます >>206。

[216] 串は、 Max-Forwards: を含む要求を転送する場合を除き、 これを生成してはなりません >>206。

[217] 要求の payload の利用方法は定義されていません >>206。

[218] 将来の HTTP の拡張により、対象資源についてより詳細に照会するために使うかもしれない >>206 とされています。

[219] 要求に payload body を含める場合、 Content-Type: ヘッダーを生成しなければなりません >>206。

[9] WebDAV に従う資源は、 OPTIONS 要求に対する応答に DAV: ヘッダーを含めなければなりません >>10, >>11。

[16] POST に対応する資源は、 Accept-Post: ヘッダーを指定するべきです >>15。

[17] この規定は LDP の仕様書に含まれているもので、主語は特に LDP 鯖に限定されているわけではなさそうなのですが、新しいヘッダーであり、 LDP 以外は従っていないようです。

文脈

[2] RFC 2817 は TLS への切り替えに OPTIONS メソッドを使っています >>4。

[203] Upgrade: ヘッダーも参照してください。

[12] WebDAV に従う資源の WebDAV 適合クラスを調べるために使うことができます >>11。

[5] >>223 は範囲単位 rows を使用する前に OPTIONS 要求に対する応答の Accept-Ranges: ヘッダーを確認することを求めています。

性質

[204] OPTIONS は、安全なメソッド >>202 で、 冪等なメソッド >>205 です。

[220] OPTIONS メソッドの要求に対する応答は、 キャッシュ可能ではありません >>206。

処理

[212] 鯖は、成功の応答を帰す場合には、 鯖が実装していて対象資源に適用できるオプション機能を示すヘッダー (例えば Allow:) を送信するべきです >>206。

[6] PATCH 要求に対応した資源に関する OPTIONS 要求への応答には、 Accept-Patch: ヘッダーを含めるべきです >>13。

[213] 応答の payload がある場合は、 通信オプションを機械可読または人間可読な形の表現で記述したものかもしれません。 ただし HTTP としてはそのような標準の形式は定義していません。 >>206

[214] 鯖は、応答に payload body を含まない場合、 Content-Length: 0 を生成しなければなりません >>206。

歴史

[1] RFC 2068・2616 (HTTP/1.1) 9.2 OPTIONS

The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

OPTIONS 方式は、 Request-URI で識別される要求・応答鎖で梨湯可能な通信選択肢についての情報を要求することを表現します。 この方式は、クライアントがある資源に関連付けられた選択肢及び/又は要件もしくはサーバーの能力を、 資源動作を課したり資源取り出しを初期化せずに決定することを可能とします。

Unless the server's response is an error, the response MUST NOT include entity information other than what can be considered as communication options (e.g., Allow is appropriate, but Content-Type is not). Responses to this method are not cacheable.

;サーバーの応答が誤りでない限り、応答は通信選択肢と考えることができるもの以外の実体情報を含めてはなりません (例えば Allow は適当ですが、 Content-Type はそうではありません)。 この方式への応答はキャッシュ可能ではありません。

If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body.

OPTION 要求が entity-body を含んでいる場合 (Content-Length や Transfer-Encoding の出現で示される。) は、 Content-Type 欄で媒体型を示さなければなりません。 この仕様書はこのような本体の使用を定義しませんが、 生来の HTTP no拡張はサーバーにより詳細に問い合わせするために OPTION 本体を使うかもしれません。 その拡張に対応していないサーバーは要求本体を捨てても構いません。

If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server as a whole in general rather than to a specific resource. A 200 response SHOULD include any header fields which indicate optional features implemented by the server (e.g., Public), including any extensions not defined by this specification, in addition to any applicable general or response-header fields. As described in section 5.1.2, an "OPTIONS *" request can be applied through a proxy by specifying the destination server in the Request-URI without any path information. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).

Request-URI が星印 (*) であるなら、その OPTION 要求は特定の資源にではなくそのサーバー一般に適用することを意図しています。200 応答は、応用可能な一般・要求頭欄に加えて、この仕様書で定義されていない拡張を含むサーバーが実装している任意選択機能を示す頭欄 (例えば Public) を含めるべきです。5.1.2 節で説明したように、 OPTIONS * 要求は終点サーバーを経路情報なしの Request-URI に指定することで串を通じて適用できます。 サーバーの通信選択肢は典型的に資源に依存しますから、 * 要求は「ping」や「no‐op」のような型の方式にのみ有用です。クライアントがサーバーの能力を検査できる以上のことは何もできません。例えば、これは串が HTTP/1.1 に適合していること (やしていないこと) を検査するのに使えます。

If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource.

Request-URI が星印ではないときは、 OPTIONS 要求は要求で通信した時に利用可能な選択肢のみに適用されます。

A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including any extensions not defined by this specification, in addition to any applicable general or response-header fields. If the OPTIONS request passes through a proxy, the proxy MUST edit the response to exclude those options which apply to a proxy's capabilities and which are known to be unavailable through that proxy. The response body, if any, SHOULD also include information about the communication options. The format for such a body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0".

200 応用は、サーバーが実装していてその資源に適用可能な任意選択機能を示す頭欄 (例えば Allow) を含めるべきです。 それはこの仕様書で定義していない拡張を含むかもしれません。 OPTIONS 要求が串を通じて渡される時は、串は応答を編集して、串の能力に適用できて串を通じては利用可能でないとわかっている選択肢を除外しなければなりません。 応答本体がある場合は、通信選択肢についての情報も含むべきです。その本体の書式はこの仕様書では定義しませんが、生来の HTTP の拡張が定義するかもしれません。適切な応答書式を選択するのに内容折衝を使っても構いません。応答本体が含まれていない時は、欄値が 0 の Content-Length 欄を含めなければなりません。

The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.

Max-Forwards 要求頭欄を、要求鎖の中の特定の串を対象とするのに使っても構いません。 串が、転送が認められている absoluteURI についての OPTIONS 要求を受取った時は、串は Max-Forwards 欄を確認しなければなりません。 Max-Forwards 欄値が零 (0) なら、 串はメッセージを転送してはなりません。 代わりに、串は自身の通信選択肢で応答するべきです。 その要求に Max-Forwards 欄がなければ、 転送する要求は Max-Forwards 欄を含んではなりません。

[18] RFC 2817 は、 Upgrade: TLS/1.0 の適用を強制したい時に OPTIONS 要求を使うことを提案していました >>4。

この方式はあまり実装されなかったようです。

[222] draft-stecher-icap-subid-00 - ICAP Extensions ( ( 版)) http://tools.ietf.org/html/draft-stecher-icap-subid-00#section-5.2

実装

[7] Apache 2.2 は静的ファイルに OPTIONS 要求を送信すると 200 を返します。 Allow: が含まれますが、その他は GET の時のヘッダーが含まれるようです。例えば Content-Type: は GET の場合のものになります。しかし本体は空になります。

[8] nginx は静的ファイルに OPTIONS 要求を送信すると 405 を返します。

[406] draft-ietf-http-options-02 - Specification of HTTP/1.1 OPTIONS messages ( ( 版)) https://tools.ietf.org/html/draft-ietf-http-options-02

[14] Linked Data Platform 1.0 ( 版) https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#h-ldpr-options-allow

4.2.8.2 LDP servers must indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow.

[19] Re: CORS performance proposal (Nottingham, Mark 著, 版) https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0808.html

it's becoming more common for content providers to ask CDNs for CORS preflight caching. Since OPTIONS doesn't fit into HTTP caching, something custom has to be designed, which means dealing with all of the corner cases, interop issues, etc.

[20] Using HTTP OPTIONS to get entity metadata | Alfresco Documentation ( 版) http://docs.alfresco.com/4.2/pra/1/concepts/pra-options.html

The Alfresco REST API supports the use of the HTTP OPTIONS method to retrieve structured information on the methods available on an entity and its relations.

[21] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-3

[22] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-3.9

[23] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-4.6

[24] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-5.5

[25] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-6.4

[26] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-7.2

[27] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-8.4

[28] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-9.5

[29] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-11.4

[30] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-12.8

[31] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-13.7

[32] RFC 3253 - Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) () https://tools.ietf.org/html/rfc3253#section-14.3

[33] Issues List for Versioning Extensions to WebDAV (RFC 3253) () http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm

[34] RFC 3648 - Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol () https://tools.ietf.org/html/rfc3648#section-10

[35] RFC 3744 - Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol () https://tools.ietf.org/html/rfc3744#section-7.2

[36] RFC 4437 - Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources () https://tools.ietf.org/html/rfc4437#section-16

[37] RFC 4791 - Calendaring Extensions to WebDAV (CalDAV) () https://tools.ietf.org/html/rfc4791#section-5.1

[38] RFC 5323 - Web Distributed Authoring and Versioning (WebDAV) SEARCH () https://tools.ietf.org/html/rfc5323#section-3.1

[39] RFC 5323 - Web Distributed Authoring and Versioning (WebDAV) SEARCH () https://tools.ietf.org/html/rfc5323#section-3.2

[40] RFC 5689 - Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) () https://tools.ietf.org/html/rfc5689#section-3.1

[41] RFC 5842 - Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) () https://tools.ietf.org/html/rfc5842#section-8.1