Access-Control-Allow-Headers

Der HTTP Access-Control-Allow-Headers Antwort-Header wird als Antwort auf eine Preflight-Anfrage verwendet, um die HTTP-Header anzugeben, die während der tatsächlichen Anfrage verwendet werden können. Dieser Header ist erforderlich, wenn die Preflight-Anfrage Access-Control-Request-Headers enthält.

Hinweis: Die CORS-safelisted Anfrage-Header sind immer erlaubt und werden normalerweise nicht in Access-Control-Allow-Headers aufgeführt, es sei denn, es besteht die Notwendigkeit, die zusätzlichen Safelist-Einschränkungen zu umgehen.

Headertyp	Antwort-Header
Verbotener Header-Name	Nein

Syntax

http

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

Direktiven

<header-name>: Der Name eines unterstützten Anfrage-Headers. Der Header kann eine beliebige Anzahl von Headern auflisten, getrennt durch Kommas.
* (Wildcard): Jeder Header. Der Wert * wird nur als spezieller Wildcard-Wert für Anfragen ohne Anmeldeinformationen gezählt (Anfragen ohne HTTP-Cookies oder HTTP-Authentifizierungsinformationen). Bei Anfragen mit Anmeldeinformationen wird es als der wörtliche Header-Name * ohne spezielle Semantik behandelt. Der Authorization Header kann nicht als Wildcard verwendet werden und muss immer explizit aufgeführt werden.

Beispiele

Implementierung eines benutzerdefinierten Headers

Unten sehen Sie ein Beispiel für einen Access-Control-Allow-Headers Header. Er zeigt an, dass ein benutzerdefinierter Header namens X-Custom-Header zusätzlich zu den CORS-safelisted Anfrage-Headern von CORS-Anfragen an den Server unterstützt wird.

http

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

Unterstützung mehrerer Header

Dieses Beispiel zeigt Access-Control-Allow-Headers, wenn die Unterstützung für mehrere Header angegeben wird.

http

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

Umgehung zusätzlicher Einschränkungen bei CORS-safelisted Headern

Obwohl CORS-safelisted Anfrage-Header immer erlaubt sind und normalerweise nicht in Access-Control-Allow-Headers aufgeführt werden müssen, wird das Auflisten dennoch die zusätzlichen Einschränkungen umgehen, die gelten.

http

Access-Control-Allow-Headers: Accept

Umgang mit Preflight-Anfragen

Sehen wir uns ein Beispiel für eine Preflight-Anfrage an, die Access-Control-Allow-Headers beinhaltet.

Anfrage

Zuerst ist die Preflight-Anfrage eine OPTIONS-Anfrage, die eine Kombination der drei Preflight-Anfrage-Header beinhaltet: Access-Control-Request-Method, Access-Control-Request-Headers, und Origin.

Die Preflight-Anfrage unten teilt dem Server mit, dass wir eine CORS GET-Anfrage mit den in Access-Control-Request-Headers aufgeführten Headern (Content-Type und X-Requested-With) senden möchten.

http

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

Antwort

Wenn die durch die Preflight-Anfrage angegebene CORS-Anfrage autorisiert ist, antwortet der Server auf die Preflight-Anfrage mit einer Nachricht, die den erlaubten Ursprung, die Methoden und die Header angibt. Unten sehen wir, dass Access-Control-Allow-Headers die angeforderten Header enthält.

http

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-Allow-Headers: Content-Type, x-requested-with
Access-Control-Max-Age: 86400

Wenn die angeforderte Methode nicht unterstützt wird, antwortet der Server mit einem Fehler.

Spezifikationen

Specification
Fetch Standard # http-access-control-allow-headers

Browser-Kompatibilität

BCD tables only load in the browser