[221] OPTIONS
メソッドは、対象資源の通信オプションについて問い合わせるものです。
[207] OPTIONS
メソッドは、
起源鯖においてあるいは中間器においての対象資源についての通信オプションに関する情報を要求するものです
>>206。
[208] これを使ってクライアントは資源に関連付けられたオプションや要件や、鯖の能力について、 資源の動作を伴わずに判定することができます >>206。
[209] 要求対象が *
の場合、特定の資源ではなく、
鯖一般に対して適用することを表します >>206。
[211] 要求対象がそれ以外の場合、当該対象資源と通信する場合のオプションに適用することを表します >>206。
[215] クライアントは、要求鎖上の特定の受信者を対象とすべく
Max-Forwards:
ヘッダーを送信することができます >>206。
[216] 串は、 Max-Forwards:
を含む要求を転送する場合を除き、
これを生成してはなりません >>206。
[217] 要求の payload の利用方法は定義されていません >>206。
[219] 要求に payload body を含める場合、 Content-Type:
ヘッダーを生成しなければなりません >>206。
[9] WebDAV に従う資源は、 OPTIONS
要求に対する応答に
DAV:
ヘッダーを含めなければなりません >>10, >>11。
[2] RFC 2817 は TLS への切り替えに OPTIONS
メソッドを使っています
>>4。
[12] WebDAV に従う資源の WebDAV 適合クラスを調べるために使うことができます >>11。
[5] >>223 は範囲単位 rows
を使用する前に
OPTIONS
要求に対する応答の Accept-Ranges:
ヘッダーを確認することを求めています。
[212] 鯖は、成功の応答を帰す場合には、
鯖が実装していて対象資源に適用できるオプション機能を示すヘッダー
(例えば Allow:
) を送信するべきです
>>206。
[6] PATCH
要求に対応した資源に関する OPTIONS
要求への応答には、 Accept-Patch:
ヘッダーを含めるべきです >>13。
[213] 応答の payload がある場合は、 通信オプションを機械可読または人間可読な形の表現で記述したものかもしれません。 ただし HTTP としてはそのような標準の形式は定義していません。 >>206
[214] 鯖は、応答に payload body を含まない場合、
Content-Length: 0
を生成しなければなりません >>206。
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 wholein 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
anyextensions 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
) を含めるべきです。
それはこの仕様書で定義していない拡張を含むかもしれません。 応答本体がある場合は、通信選択肢についての情報も含むべきです。その本体の書式はこの仕様書では定義しませんが、生来の HTTP の拡張が定義するかもしれません。適切な応答書式を選択するのに内容折衝を使っても構いません。応答本体が含まれていない時は、欄値が OPTIONS
要求が串を通じて渡される時は、串は応答を編集して、串の能力に適用できて串を通じては利用可能でないとわかっている選択肢を除外しなければなりません。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>
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.
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.
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>