En-tête Access-Control-Allow-Headers

Baseline Widely available *

Cette fonctionnalité est bien établie et fonctionne sur de nombreux appareils et versions de navigateurs. Elle est disponible sur tous les navigateurs depuis juillet 2015.

* Certaines parties de cette fonctionnalité peuvent bénéficier de prise en charge variables.

L'en-tête de réponse HTTPAccess-Control-Allow-Headers est utilisé en réponse à unerequête préliminaire pour indiquer les en-têtes HTTP qui peuvent être utilisés lors de la requête réelle.Cet en-tête est requis si la requête préliminaire contientAccess-Control-Request-Headers.

Note :Lesen-têtes de requête sûrs pour le CORS sont toujours autorisés et ne sont généralement pas listés dansAccess-Control-Allow-Headers sauf s'il est nécessaire de contourner lesrestrictions supplémentaires de la liste sûre.

Type d'en-tête	En-tête de réponse

Syntaxe

http

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

Directives

<header-name>: Le nom d'un en-tête de requête pris en charge. L'en-tête peut lister n'importe quel nombre d'en-têtes, séparés par des virgules.
* (joker): Tout en-tête.La valeur* n'est considérée comme une valeur joker spéciale que pour les requêtes sans justificatifs (requêtes sanscookies HTTP ou information d'authentification HTTP).Pour les requêtes avec justificatifs, elle est traitée comme le nom d'en-tête littéral* sans sémantique particulière.L'en-têteAuthorization n'accepte pas le joker et doit toujours être listé explicitement.

Exemples

Implémentation d'un en-tête personnalisé

Voici un exemple d'en-têteAccess-Control-Allow-Headers.Il indique qu'un en-tête personnalisé nomméX-Custom-Header est pris en charge par les requêtes CORS vers le serveur, en plus desen-têtes de requête sûrs pour le CORS.

http

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

Prise en charge de plusieurs en-têtes

Cet exemple montreAccess-Control-Allow-Headers lorsqu'il indique la prise en charge de plusieurs en-têtes.

http

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

Contournement des restrictions supplémentaires sur les en-têtes sûrs pour le CORS

Bien que lesen-têtes de requête sûrs pour le CORS soient toujours autorisés et n'aient généralement pas besoin d'être listés dansAccess-Control-Allow-Headers, les lister permet de contourner lesrestrictions supplémentaires qui s'appliquent.

http

Access-Control-Allow-Headers: Accept

Gestion des requêtes préliminaires

Voici un exemple derequête préliminaire impliquantAccess-Control-Allow-Headers.

Requête

Tout d'abord, la requête préliminaire est une requêteOPTIONS qui inclut une combinaison des trois en-têtes de requête préliminaire :Access-Control-Request-Method,Access-Control-Request-Headers etOrigin.

La requête préliminaire ci-dessous indique au serveur que nous souhaitons envoyer une requête CORSGET avec les en-têtes listés dansAccess-Control-Request-Headers (Content-Type etX-Requested-With).

http

OPTIONS /resource/fooAccess-Control-Request-Method: GETAccess-Control-Request-Headers: content-type,x-requested-withOrigin: https://www.example.com

Réponse

Si la requête CORS indiquée par la requête préliminaire est autorisée, le serveur répondra à la requête préliminaire avec un message indiquant l'origine, les méthodes et les en-têtes autorisés. Ci-dessous, on voit queAccess-Control-Allow-Headers inclut les en-têtes demandés.

http

HTTP/1.1 200 OKContent-Length: 0Connection: keep-aliveAccess-Control-Allow-Origin: https://www.example.comAccess-Control-Allow-Methods: POST, GET, OPTIONS, DELETEAccess-Control-Allow-Headers: Content-Type, x-requested-withAccess-Control-Max-Age: 86400

Si la méthode demandée n'est pas prise en charge, le serveur répondra avec une erreur.