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 か、サーバー全体を表すアスタリスク (*) を指定することができます。
* OPTIONS メッセージにリクエスト本体を付けることは技術的に認められているものの、その意味づけは定義されていません。
OPTIONS メッセージに本体を含めることは可能です。ただし、有効な Content-Type ヘッダーを提供し、かつサーバーがそれを期待していることがわかっている場合に限ります。この動作は実装依存です。
構文
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 リクエストを発行してください。
curl -X OPTIONS https://example.org -i
これは以下の HTTP リクエストを生成します。
OPTIONS / HTTP/2
Host: example.org
User-Agent: curl/8.7.1
Accept: */*
レスポンスには、許可されているメソッドが入った Allow ヘッダーが含まれています。
HTTP/1.1 204 No Content
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
CORS でのプリフライトリクエスト
CORS では、プリフライトリクエストを OPTIONS メソッドで送信すると、サーバーはリクエストを送信して受け付けられるかどうかを応答できるようにします。下記の例では、次の引数に対する許可を要求します。
- プリフライトリクエストで送信される
Access-Control-Request-Methodヘッダーは、実際のリクエストを送信する際に、リクエストメソッドがPOSTであることをサーバーに知らせます。 Access-Control-Request-Headersヘッダーは、実際のリクエスト送信時にX-PINGOTHERとContent-Typeヘッダーを持つことをサーバーに知らせます。
OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.example
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: https://foo.example
Access-Control-Request-Method: POST
Access-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/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
メモ:
200 OK と 204 No Content の両方が 許可されているステータスコードですが、ブラウザーによっては誤って 204 No Content がリソースに適用されると判断し、その後リソースを取得するためのリクエストを送信しないことがあります。
仕様書
| Specification |
|---|
| HTTP Semantics> # OPTIONS> |