Access-Control-Allow-Headers
Baseline Widely available *
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
* Some parts of this feature may have varying levels of support.
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 eigentlichen Anfrage verwendet werden können. Dieser Header ist erforderlich, wenn die Preflight-Anfrage Access-Control-Request-Headers
enthält.
Hinweis:
Die CORS-safelisted request headers 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.
Header-Typ | Antwort-Header |
---|---|
Verbotener Anforderungs-Header | Nein |
Syntax
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 Anforderungs-Headers. Der Header kann eine beliebige Anzahl von Headern enthalten, getrennt durch Kommas.
*
(Wildcard)-
Jeder Header. Der Wert
*
zählt nur als spezieller Wildcard-Wert für Anfragen ohne Anmeldedaten (Anfragen ohne HTTP-Cookies oder HTTP-Authentifizierungsinformationen). Bei Anfragen mit Anmeldedaten wird er als der wörtliche Header-Name*
ohne besondere Semantik behandelt. DerAuthorization
-Header akzeptiert keine Wildcards und muss immer explizit aufgeführt werden.
Beispiele
Implementierung eines benutzerdefinierten Headers
Unten ist ein Beispiel für einen Access-Control-Allow-Headers
Header.
Es zeigt an, dass ein benutzerdefinierter Header namens X-Custom-Header
von CORS-Anfragen an den Server unterstützt wird, zusätzlich zu den CORS-safelisted request headers.
Access-Control-Allow-Headers: X-Custom-Header
Unterstützung mehrerer Header
Dieses Beispiel zeigt Access-Control-Allow-Headers
, wenn es die Unterstützung für mehrere Header spezifiziert.
Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests
Umgehung zusätzlicher Einschränkungen bei CORS-safelisted-Headern
Obwohl CORS-safelisted request headers immer erlaubt sind und normalerweise nicht in Access-Control-Allow-Headers
aufgeführt werden müssen, wird durch ihre Auflistung dennoch die zusätzlichen Einschränkungen umgangen, die gelten.
Access-Control-Allow-Headers: Accept
Umgang mit Preflight-Anfragen
Schauen 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-Anforderungs-Header: Access-Control-Request-Method
, Access-Control-Request-Headers
und Origin
enthält.
Die folgende Preflight-Anfrage 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.
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 Header angibt. Unten sehen wir, dass Access-Control-Allow-Headers
die angeforderten Header enthält.
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 # http-access-control-allow-headers |