#?SuikaWiki/0.9

[[#comment]]
* 仕様書から
** 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.

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

> [DEL[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 cach[INS[e]]able.

;[DEL[サーバーの応答が[[誤り]]でない限り、応答は通信選択肢と考えることができるもの以外の[[実体]]情報を含めては'''なりません''' (例えば [CODE(HTTP)[[[Allow]]]] は適当ですが、 [CODE(HTTP)[[[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.

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

> If the Request-URI is an asterisk ("*"), the OPTIONS request is
intended to apply to the server [DEL[as a whole]] [INS[in general rather than to a specific resource]]. [DEL[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.]] [INS[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).]]

[CODE(ABNF)[[[Request-URI]]]] が星印 ([CODE(HTTP)[*]])
であるなら、その [CODE(HTTP)[OPTION]] 要求は特定の資源にではなくそのサーバー一般に適用することを意図しています。[DEL[[CODE(HTTP)[[[200]]]] 応答は、応用可能な一般・要求頭欄に加えて、この仕様書で定義されていない拡張を含むサーバーが実装している任意選択機能を示す頭欄 (例えば [CODE(HTTP)[[[Public]]]]) を含める'''べきです'''。5.1.2 節で説明したように、 [CODE(HTTP)[OPTIONS *]] 要求は終点サーバーを経路情報なしの [CODE(ABNF)[Request-URI]] に指定することで[[串]]を通じて適用できます。]] [INS[サーバーの通信選択肢は典型的に資源に依存しますから、 [CODE(HTTP)[*]] 要求は「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.

[CODE(ABNF)[Request-URI]] が星印ではないときは、 [CODE(HTTP)[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), [INS[possibly]] including [DEL[any]] extensions not defined by this specification[DEL[, in addition to any applicable general or response-header fields]]. [DEL[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.]] [INS[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".]]

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

[INS[
> 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.

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