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 欄を含めなければなりません。

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.