Liste des champs d'en-tête HTTP

Cet article répertorie les champs d'en-tête HTTP standard et non standard notables.

Un ensemble de champs de base est normalisé par l'Internet Engineering Task Force (IETF) dans les RFC 9110 et RFC 9111. Les noms de champs, les champs d'en-tête et le référentiel des enregistrements provisoires sont gérés par l'IANA. Des champs supplémentaires peuvent être définis par une application web.

Dans le passé, les noms de champs d'en-tête non standard étaient préfixés par X-, mais cette convention a été dépréciée en juin 2012 en raison des inconvénients qu'elle causait lorsque les champs non standard devenaient standard. Une restriction antérieure sur l'utilisation de Downgraded- a été levée en mars 2013.

Certaines valeurs de champ peuvent contenir des commentaires (par exemple dans les champs User-Agent, Server, Via), qui peuvent être ignorés par le logiciel.

De nombreuses valeurs de champ peuvent contenir une paire clé-valeur de qualité (q) séparée par un signe égal, spécifiant un poids à utiliser dans la négociation de contenu. Par exemple, un navigateur peut indiquer qu'il accepte les informations en allemand ou en anglais, l'allemand étant la langue préférée, en attribuant à la valeur q de de une valeur supérieure à celle de en, comme suit :

Accept-Language: de; q=1.0, en; q=0.5

Champs de requête

Cette section répertorie les champs d'en-tête utilisés dans une requête.

Champs de requête standard

A-IM

[RFC 3229, permanent] Manipulations d'instance acceptables pour la requête.

Par exemple : A-IM: feed

Accept

[RFC 9110, permanent] Type(s) de média(s) acceptable(s) pour la réponse. Voir Négociation de contenu.

Par exemple : Accept: text/html

Accept-Charset

[RFC 9110, permanent] Jeux de caractères acceptables.

Par exemple : Accept-Charset: utf-8

Accept-Datetime

[RFC 7089, provisoire] Version acceptable à temps.

Par exemple : Accept-Datetime: Fri, 31 Jul 2026 09:34:00 GMT

Accept-Encoding

[RFC 9110, permanent] Liste des encodages acceptables. Voir la compression HTTP.

Par exemple : Accept-Encoding: gzip, deflate

Accept-Language

[RFC 9110, permanent] Liste des langues humaines acceptables pour la réponse. Voir Négociation de contenu.

Par exemple : Accept-Language: fr-FR

Access-Control-Request-Method, Access-Control-Request-Headers

[permanent] Lance une requête de partage de ressources inter-origines avec Origin (ci-dessous).

Par exemple : Access-Control-Request-Method: GET

Authorization

[RFC 9110, permanent] Informations d'identification d'authentification pour l'authentification HTTP.

Par exemple : Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Cache-Control

[RFC 9111, permanent] Utilisé pour spécifier les directives auxquelles doivent obéir tous les mécanismes de mise en cache le long de la chaîne requête-réponse. Conformément à la norme HTTP/1.1, la valeur no-cache permet au navigateur d'indiquer au serveur et aux caches intermédiaires qu'il souhaite une version actualisée de la ressource. En HTTP/1.0, le champ d'en-tête Pragma: no-cache a le même objectif.

Le comportement de no-cache dans une réponse n'est pas spécifié, mais certains agents utilisateurs le prennent en charge. La norme HTTP/1.1 met spécifiquement en garde contre le fait de se fier à ce comportement.

Par exemple : Cache-Control: no-cache

Connection

[RFC 9110, permanent] Options de contrôle pour la connexion actuelle et liste des champs de requête de saut en saut. Ne doit pas être utilisé avec HTTP/2.

Par exemple : Connection: keep-alive Connection: Upgrade

Content-Digest

[RFC 9530, Champs Digest] L'en-tête Content-Digest permet de vérifier l'intégrité du contenu du message en calculant un condensé sur les octets littéraux transmis dans le message HTTP. Ce résumé reflète le contenu après application de transformations telles que l'encodage de contenu, correspondant exactement à ce qui transite sur le réseau.

Content-Encoding

[RFC 9110, permanent] Le type d'encodage utilisé sur les données. Voir la compression HTTP.

Par exemple : Content-Encoding: gzip

Content-Length

[RFC 9110, permanent] La longueur du corps de la requête en octets (octets de 8 bits).

Par exemple : Content-Length: 348

Content-MD5

[RFC 1544, 1864, 4021, obsolète] Somme MD5 binaire encodée en Base64 du contenu du corps de la requête.

Par exemple : Content-MD5: VGhlIGNha2UgaXMgYSBsaWUgIQ==

Content-Type

[RFC 9110, permanent] Le type de média du corps de la requête (utilisé avec les requêtes POST et PUT).

Par exemple : Content-Type: application/x-www-form-urlencoded

Cookie

[RFC 2965, 6265, permanent] Un cookie HTTP précédemment envoyé par le serveur avec Set-Cookie (ci-dessous).

Par exemple : Cookie: $Version=1; Skin=new;

Date

[RFC 9110, permanent] La date et l'heure auxquelles le message a été créé (au format « HTTP-date » tel que défini par RFC 9110 : Sémantique HTTP, section 5.6.7 « Formats de date/heure » ).

Par exemple : Date: Tue, 15 Nov 1994 08:12:31 GMT

Expect

[RFC 9110, permanent] Indique que certains comportements du serveur sont requis par le client.

Par exemple : Expect: 100-continue

Forwarded

[RFC 7239, permanent] Divulguer les informations originales d'un client se connectant à un serveur Web via un proxy HTTP.

Par exemple : Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43 Forwarded: for=192.0.2.43, for=198.51.100.17

From

[RFC 9110, permanent] L'adresse e-mail de l'utilisateur effectuant la demande.

Par exemple : From: utilisateur@exemple.com

Host

[RFC 9110, 9113, permanent] Le nom de domaine du serveur (pour l'hébergement virtuel) et le numéro de port TCP sur lequel le serveur est à l'écoute. Le numéro de port peut être omis si le port est le port standard du service demandé. Obligatoire depuis HTTP/1.1. Si la requête est générée directement en HTTP/2, elle ne doit pas être utilisée.

Par exemple : Host: fr.wikipedia.org:8080 Host: fr.wikipedia.org

HTTP2-Settings

[RFC 7540, 9113, obsolète] Une requête qui passe de HTTP/1.1 à HTTP/2 DOIT inclure exactement un champ d'en-tête HTTP2-Settings. Le champ d'en-tête HTTP2-Settings est un champ d'en-tête spécifique à la connexion qui inclut des paramètres régissant la connexion HTTP/2, fournis en prévision de l'acceptation par le serveur de la demande de mise à niveau.

Par exemple : HTTP2-Settings: token64

If-Match

[RFC 9110, permanent] N'effectuez l'action que si l'entité fournie par le client correspond à la même entité sur le serveur. Cela concerne principalement les méthodes comme PUT, qui permettent de mettre à jour une ressource uniquement si elle n'a pas été modifiée depuis la dernière mise à jour par l'utilisateur.

Par exemple : If-Match: "737060cd8c284d8af7ad3082f209582d"

If-Modified-Since

[RFC 9110, permanent] Permet de renvoyer un code 304 Not Modified si le contenu est inchangé.

Par exemple : If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

If-None-Match

[RFC 9110, permanent] Permet de renvoyer un code 304 Not Modified si le contenu est inchangé, voir HTTP ETag.

Par exemple : If-None-Match: "737060cd8c284d8af7ad3082f209582d"

If-Range

[RFC 9110, permanent] Si l'entité est inchangée, envoyez-moi la ou les parties qui me manquent ; sinon, envoyez-moi la nouvelle entité complète.

Par exemple : If-Range: "737060cd8c284d8af7ad3082f209582d"

If-Unmodified-Since

[RFC 9110, permanent] N'envoyer la réponse que si l'entité n'a pas été modifiée depuis une heure spécifique.

Par exemple : If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Max-Forwards

[RFC 9110, permanent] Limiter le nombre de fois où le message peut être transféré via des proxys ou des passerelles.

Par exemple : Max-Forwards: 10

Origin

[RFC 6454, permanent] Initie une requête de partage de ressources inter-origines (demande au serveur les champs de réponse Access-Control-*).

Par exemple : Origin: http://www.example-social-network.com

Pragma

[RFC 9111, obsolète] Champs spécifiques à l'implémentation qui peuvent avoir divers effets à n'importe quel endroit de la chaîne requête-réponse.

Par exemple : Pragma: no-cache

Prefer

[RFC 7240, permanent] Permet au client de demander à un serveur d'adopter certains comportements lors du traitement d'une requête.

Par exemple : Prefer: return=representation

Proxy-Authorization

[RFC 9110, permanent] Informations d'identification d'autorisation pour la connexion à un proxy.

Par exemple : Proxy-Authorization: Basic QWxhZGRpbjpTw6lzYW1lLCBvdXZyZS10b2k=

Range

[RFC 9110, permanent] Demander uniquement une partie d'une entité. Les octets sont numérotés à partir de 0. Voir Byte servant.

Par exemple : Range: bytes=500-999

Referer [sic]

[RFC 9110, permanent] L'adresse de la page Web précédente à partir de laquelle un lien vers la page actuellement demandée a été suivi.

Bien que le terme voulu s'écrive en réalité « referrer », l'orthographe erronée figure dans la RFC ainsi que dans la plupart des implémentations et est donc considérée comme une terminologie correcte.

Par exemple : Referer: https://fr.wikipedia.org/wiki/Wikipédia:Accueil_principal

TE

[RFC 9110, permanent] Les encodages de transfert que l'agent utilisateur est prêt à accepter : les mêmes valeurs que pour le champ d'en-tête de réponse Transfer-Encoding peuvent être utilisées, plus la valeur « trailers » (liée à la méthode de transfert « chunked ») pour informer le serveur qu'il s'attend à recevoir des champs supplémentaires dans la remorque après le dernier bloc de taille nulle. Seules trailers sont prises en charge par HTTP/2.

Par exemple : TE: trailers, deflate

Trailer

[RFC 9110, permanent] La valeur du champ général Trailer indique que l'ensemble donné de champs d'en-tête est présent dans la fin d'un message encodé avec un codage de transfert par blocs.

Par exemple : Trailer: Max-Forwards

Transfer-Encoding

[RFC 9110, permanent] La forme d'encodage utilisée pour transférer en toute sécurité l'entité à l'utilisateur. Les méthodes actuellement définies sont : chunked, compress, deflate, gzip, identity. Ne doit pas être utilisé avec HTTP/2.

Par exemple : Transfer-Encoding: chunked

User-Agent

[RFC 9110, permanent] La chaîne d'agent utilisateur de l'agent utilisateur.

Par exemple : User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0

Upgrade

[RFC 9110, permanent] Demander au serveur de passer à un autre protocole. Ne doit pas être utilisé dans HTTP/2.

Par exemple : Upgrade: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket

Via

[RFC 9110, permanent] Informe le serveur des proxys par lesquels la requête a été envoyée.

Par exemple : Via: 1.0 fred, 1.1 exemple.com (Apache/1.1)

Warning

[RFC 7234, 9111, obsolète] Avertissement concernant un problème possible avec le corps de l'entité. Étant donné que cet en-tête n'est souvent ni envoyé par les serveurs ni accusé de réception par les clients, cet en-tête et ses codes ont été déclarés obsolètes par le groupe de travail HTTP en 2022 avec RFC 9111.

Les codes d'avertissement suivants relatifs à la mise en cache ont été spécifiés dans la RFC 7234.

110 Réponse obsolète

La réponse fournie par un cache est obsolète (l'âge du contenu dépasse un âge maximal défini par un en-tête Cache-Control ou une durée de vie choisie de manière heuristique).

111 Échec de la revalidation

Le cache n'a pas pu valider la réponse, car il était impossible de joindre le serveur d'origine.

112 Fonctionnement déconnecté

Le cache est intentionnellement déconnecté du reste du réseau.

113 Expiration heuristique

Le cache a choisi de manière heuristique une durée de fraîcheur supérieure à 24 heures et l'âge de la réponse est supérieur à 24 heures.

199 Avertissements divers

Avertissement arbitraire et non spécifique. Le texte d'avertissement peut être enregistré ou affiché à l'utilisateur.

214 Transformation appliquée

Ajouté par un proxy s'il applique une transformation quelconque à la représentation, comme la modification de l'encodage du contenu, du type de média ou autre.

299 Avertissements persistants divers

Identique à 199, mais indiquant un avertissement persistant.

Par exemple : Warning: 199 Miscellaneous warning

X-XSS-Protection

Filtre anti-cross-site scripting (XSS)

Par exemple : X-XSS-Protection: 1; mode=block

Voir aussi

• Liste des codes d'état HTTP

Références

(en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « List of HTTP header fields » (voir la liste des auteurs).