Access-Control-Allow-Headers

Access-Control-Allow-Headers: <header-name>[, <header-name>]*
Access-Control-Allow-Headers: *

<header-name>

対応しているリクエストヘッダーの名前です。ヘッダーはコンマで区切って、任意の数のリストにすることができます。

* (ワイルドカード)

"*" の値は、資格情報のないリクエスト (HTTP Cookie や HTTP の認証情報のないリクエスト) の特殊なワイルドカード値です。認証情報付きのリクエストでは、特別な意味のない "*" というヘッダー名として扱われます。なお、 Authorization ヘッダーはワイルドカードで表すことができず、常に明示的に列挙する必要があります。

CORS セーフリストリクエストヘッダー, Accept, Accept-Language, Content-Language, Content-Type は常に許可されており、このヘッダーで列挙する必要はありません。しかし、これらのヘッダーを Access-Control-Allow-Headers に列挙することで、これらのヘッダーでも追加の制約の適用を回避することができることに注意してください。

Access-Control-Allow-Headers ヘッダーがどのように見えるかの例です。CORS セーフリストリクエストヘッダーに加えて、 X-Custom-Header という名前のカスタムヘッダーがサーバーへの CORS リクエストで対応しています。

Access-Control-Allow-Headers: X-Custom-Header

この例は、複数のヘッダーへの対応を指定するときの Access-Control-Allow-Headers を示しています。

Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests

CORS セーフリストリクエストヘッダーは常に許可され、ふつうは Access-Control-Allow-Headers に列挙する必要はありませんが、それでも列挙すれば追加の制約が適用されることを回避できます。

Access-Control-Allow-Headers: Accept

Access-Control-Allow-Headers を伴うプリフライトリクエストの例を見てみましょう。

リクエスト

最初にリクエストです。プリフライトリクエストは OPTIONS リクエストで、次のように 3 つのプリフライトリクエストヘッダー、 Access-Control-Request-Method, Access-Control-Request-Headers, Origin の組み合わせを含みます。

OPTIONS /resource/foo
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: origin, x-requested-with
Origin: https://foo.bar.org

レスポンス

CORS リクエストが DELETE メソッドを使うことをサーバーが許可した場合、 Access-Control-Allow-Methods レスポンスヘッダーで返信し、そこでは DELETE とともに対応するその他のメソッドのリストが含まれます。

HTTP/1.1 200 OK
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: https://foo.bar.org
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400

要求されたメソッドに対応していない場合は、サーバーはエラーを返します。

• Access-Control-Allow-Origin
• Access-Control-Expose-Headers
• Access-Control-Allow-Methods
• Access-Control-Request-Headers