OPTIONS リクエストメソッド

Baseline Widely available

This feature is well established and works across many devices and browser versions. It’s been available across browsers since 2015年7月.

HTTP のOPTIONSメソッドは、指定された URL またはサーバーの許可されている通信オプションをリクエストします。これを使用して、リクエストで許可されている HTTP メソッドを検査したり、CORS プリフライトリクエストを実行した際にリクエストが成功するかどうかを判断したりできます。クライアントはこのメソッドで URL か、サーバー全体を表すアスタリスク (*) を指定することができます。

リクエストの本文	可*
成功時のレスポンスの本文	可
安全性	あり
べき等性	あり
キャッシュ	不可
HTML フォームでの使用	不可

*OPTIONS メッセージにリクエスト本体を付けることは技術的に認められているものの、その意味づけは定義されていません。OPTIONS メッセージに本体を含めることは可能です。ただし、有効なContent-Type ヘッダーを提供し、かつサーバーがそれを期待していることがわかっている場合に限ります。この動作は実装依存です。

構文

http

OPTIONS *|<request-target>["?"<query>] HTTP/1.1

リクエスト対象は、サーバー全体を示す「アスタリスク形式」*、または他のメソッドで一般的なリクエスト対象のどちらかになります。

*: クライアントが、そのサーバーの特定の名前付きリソースではなく、サーバー全体に対してOPTIONS をリクエストすることを希望していることを示します。
<request-target>: Host ヘッダーで指定された情報と組み合わせて、リクエストの対象リソースを特定します。これは、オリジンサーバーへのリクエストでは絶対パス（例：/path/to/file.html）であり、プロキシーへのリクエストでは絶対 URL（例：http://www.example.com/path/to/file.html）です。
<query>省略可: 疑問符? で始まるオプションのクエリー成分です。しばしば識別情報をkey=value の組という形で保持するために使用されます。

例

許可されたリクエストメソッドの識別

サーバーが対応しているリクエストメソッドを調べるには、curl を使用してOPTIONS リクエストを発行してください。

bash

curl -X OPTIONS https://example.org -i

これは以下の HTTP リクエストを生成します。

http

OPTIONS / HTTP/2Host: example.orgUser-Agent: curl/8.7.1Accept: */*

レスポンスには、許可されているメソッドが入ったAllow ヘッダーが含まれています。

http

HTTP/1.1 204 No ContentAllow: OPTIONS, GET, HEAD, POSTCache-Control: max-age=604800Date: Thu, 13 Oct 2016 11:45:00 GMTServer: EOS (lax004/2813)

CORS でのプリフライトリクエスト

CORS では、プリフライトリクエストをOPTIONS メソッドで送信すると、サーバーはリクエストを送信して受け付けられるかどうかを応答できるようにします。下記の例では、次の引数に対する許可を要求します。

プリフライトリクエストで送信されるAccess-Control-Request-Method ヘッダーは、実際のリクエストを送信する際に、リクエストメソッドがPOST であることをサーバーに知らせます。
Access-Control-Request-Headers ヘッダーは、実際のリクエスト送信時にX-PINGOTHER とContent-Type ヘッダーを持つことをサーバーに知らせます。

http

OPTIONS /resources/post-here/ HTTP/1.1Host: bar.exampleAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateConnection: keep-aliveOrigin: https://foo.exampleAccess-Control-Request-Method: POSTAccess-Control-Request-Headers: content-type,x-pingother

サーバーは、このような状況下でリクエストを受け入れるかどうかを応答することができるようになりました。下記の例では、サーバーのレスポンスは次のように言っています。

Access-Control-Allow-Origin: https://foo.example のオリジンは、以下の方法でbar.example/resources/post-here/ の URL をリクエストすることが許可されています。
Access-Control-Allow-Methods: POST,GET,OPTIONS がその URL で許可されているメソッドです。（このヘッダーはAllow レスポンスヘッダーに似ていますが、CORS でのみ使用します。）
Access-Control-Allow-Headers: レスポンスを検査するスクリプトはX-PINGOTHER とContent-Type ヘッダーの値を読み取ることが許可されます。
Access-Control-Max-Age: 上記の許可は、 86,400 秒（1 日）キャッシュされる可能性があります。

http

HTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:15:39 GMTServer: Apache/2.0.61 (Unix)Access-Control-Allow-Origin: https://foo.exampleAccess-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control-Allow-Headers: X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400Vary: Accept-Encoding, OriginKeep-Alive: timeout=2, max=100Connection: Keep-Alive

メモ:200 OK と204 No Content の両方が許可されているステータスコードですが、ブラウザーによっては誤って204 No Content がリソースに適用されると判断し、その後リソースを取得するためのリクエストを送信しないことがあります。