Access-Control-Allow-Methods

使い方

単純ではないメソッドでクロスオリジンのリクエストを送る前に、ブラウザはプリフライトの OPTIONS リクエストを発行します。プリフライトの Access-Control-Request-Method ヘッダーは、クライアントが使おうとしているメソッドを示します。サーバーは、対象リソースに対してどのメソッドを受け入れるかを示す Access-Control-Allow-Methods で応答します。

単純なメソッド（GET、HEAD、POST）は CORS プロトコルによって常に許可されており、厳密にはここに列挙する必要はありません。明示的に列挙するのは一般的な慣習で、サーバーのポリシーが一目で分かるようになります。

複数のメソッドはカンマ区切りのリストとして現れます。

メソッド名のリスト

サーバーがクロスオリジンのアクセスで受け入れる HTTP メソッド名を、カンマ区切りで並べたものです。

Access-Control-Allow-Methods: GET, POST, PUT, DELETE

*（ワイルドカード）

アスタリスクは認証情報を伴わないリクエストに対するワイルドカードとして機能し、任意のメソッドを許可します。

Access-Control-Allow-Methods: *

注意

認証情報を伴うリクエストでは、ワイルドカード * はワイルドカードではなくリテラル文字列として扱われます。認証情報が存在する場合、許可する各メソッドを明示的に列挙しなければなりません。

例

プリフライトのリクエストが、PUT メソッドが許可されているかを尋ねます。サーバーは複数のメソッドを許可することを伝えます。

リクエスト

OPTIONS /api/resource/42 HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: PUT

レスポンス

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Max-Age: 7200

より制限的なサーバーは GET と POST だけを許可します。

Access-Control-Allow-Methods: GET, POST

トラブルシューティング

HTTP メソッドに関連するプリフライトの失敗は、サーバーが本来の操作を処理する前に実際のクロスオリジンリクエストをブロックします。

コンソールに「Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.」と表示される。サーバーが Access-Control-Allow-Methods の値に要求されたメソッドを含めていません。不足しているメソッドをプリフライトのレスポンスに追加してください。nginx では add_header Access-Control-Allow-Methods “GET, POST, PUT, DELETE, PATCH”; Apache では Header set Access-Control-Allow-Methods “GET, POST, PUT, DELETE, PATCH” とします。

プリフライトのレスポンスにヘッダーがまったく含まれない。OPTIONS のハンドラーは存在するものの、Access-Control-Allow-Methods を返していません。プリフライトのルートが Access-Control-Allow-Origin や Access-Control-Allow-Headers と併せてこのヘッダーを設定していることを確認してください。メソッドのヘッダーが欠けていると、ブラウザは単純ではないメソッドをすべて拒否します。

ワイルドカード * が認証情報を伴うリクエストで機能しない。Access-Control-Allow-Credentials が true の場合、ワイルドカードはリテラル文字列 * として扱われ、どのメソッドにも一致しません。認証情報を伴う構成では、許可する各メソッドを明示的に列挙してください。

プリフライト中にサーバーが 405 Method Not Allowed を返す。対象 URL の OPTIONS を処理するルートがサーバーに存在しないため、リクエストがメソッドを拒否するキャッチオールに到達しています。そのルートに OPTIONS のハンドラーを追加してください。Express では app.options(‘/api/resource’, cors()) とします。Django では django-cors-headers ミドルウェアを導入すると OPTIONS が自動的に処理されます。nginx では if ($request_method = OPTIONS) のブロックを追加するか、limit_except を使ってその location で OPTIONS を許可します。

フレームワークが OPTIONS を自動処理するが CORS ヘッダーを含めない。一部のフレームワークは OPTIONS に対して 200 または 204 と、サポートするメソッドを列挙した素の Allow ヘッダーで応答しますが、CORS ヘッダーは一切付けません。Access-Control-Allow-Methods がないため、ブラウザはこれをプリフライトの失敗として扱います。フレームワーク組み込みのハンドラーより前に OPTIONS リクエストを横取りするよう CORS ミドルウェアを構成してください。Spring Boot では CorsFilter の Bean を登録します。ASP.NET では app.UseRouting() の前に正しいポリシーで services.AddCors() を呼び出します。