5. Request Header Fields (Champs d'en-tête de requête)

Un client envoie des champs d'en-tête de requête pour fournir plus d'informations sur le contexte de la requête, rendre la requête conditionnelle en fonction de l'état de la ressource cible, suggérer des formats préférés pour la réponse, fournir des informations d'identification d'authentification ou modifier le traitement attendu de la requête. Ces champs agissent comme des modificateurs de requête, similaires aux paramètres d'un appel de méthode dans un langage de programmation.

5.1. Controls (Contrôles)

Les contrôles sont des champs d'en-tête de requête qui dirigent le traitement spécifique de la requête.

5.1.1. Expect (Attente)

Le champ d'en-tête Expect dans une requête indique un certain ensemble de comportements (attentes) qui doivent être pris en charge par le serveur afin de traiter correctement cette requête. La seule attente définie par cette spécification est 100-continue.

Expect = "100-continue"

La valeur du champ Expect est insensible à la casse.

Un serveur qui reçoit une valeur de champ Expect autre que 100-continue peut répondre avec un code d'état 417 (Expectation Failed) pour indiquer que l'attente inattendue ne peut pas être satisfaite.

Une attente 100-continue informe les destinataires que le client est sur le point d'envoyer un corps de message (probablement volumineux) dans cette requête et souhaite recevoir une réponse intermédiaire 100 (Continue) si la méthode, l'URI cible et les champs d'en-tête ne sont pas suffisants pour provoquer une réponse de succès, de redirection ou d'erreur immédiate. Cela permet au client d'attendre une indication qu'il vaut la peine d'envoyer le corps du message avant de le faire réellement, ce qui peut améliorer l'efficacité lorsque le corps du message est volumineux ou lorsque le client s'attend à ce qu'une erreur soit probable (par exemple, lors de l'envoi d'une méthode qui modifie l'état, pour la première fois, sans informations d'identification d'authentification préalablement vérifiées).

Par exemple :

Expect: 100-continue

Un client qui envoie une attente 100-continue n'est pas tenu d'attendre pendant une période de temps spécifique ; un tel client peut (MAY) continuer à envoyer le corps du message même s'il n'a pas encore reçu de réponse. De plus, étant donné que les réponses 100 (Continue) ne peuvent pas être envoyées via un intermédiaire HTTP/1.0, un tel client ne devrait pas (SHOULD NOT) attendre indéfiniment avant d'envoyer le corps du message.

Exigences pour les clients :

• Un client ne doit pas (MUST NOT) générer une attente 100-continue dans une requête qui n'inclut pas de corps de message.

Exigences pour les serveurs :

• Un serveur qui reçoit une attente 100-continue dans une requête HTTP/1.0 doit (MUST) ignorer cette attente.
• Un serveur peut (MAY) omettre d'envoyer une réponse 100 (Continue) s'il a déjà reçu tout ou partie du corps du message pour la requête correspondante, ou si le cadrage indique qu'il n'y a pas de corps de message.
• Un serveur qui envoie une réponse 100 (Continue) doit (MUST) finalement envoyer un code d'état final, une fois que le corps du message est reçu et traité, sauf si la connexion est fermée prématurément.
• Un serveur qui répond avec un code d'état final avant de lire l'intégralité du corps du message devrait (SHOULD) indiquer dans cette réponse s'il a l'intention de fermer la connexion ou de continuer à lire et à rejeter le message de requête (voir Section 6.6 de [RFC7230]).

5.1.2. Max-Forwards (Transferts maximum)

Le champ d'en-tête Max-Forwards fournit un mécanisme avec les méthodes de requête TRACE (Section 4.3.8) et OPTIONS (Section 4.3.7) pour limiter le nombre de fois que la requête est transférée par des proxys. Cela peut être utile lorsque le client tente de tracer une requête qui semble échouer ou boucler au milieu de la chaîne.

Max-Forwards = 1*DIGIT

La valeur Max-Forwards est un entier décimal indiquant le nombre restant de fois que ce message de requête peut être transféré.

Chaque intermédiaire qui reçoit une requête TRACE ou OPTIONS contenant un champ d'en-tête Max-Forwards doit (MUST) vérifier et mettre à jour sa valeur avant de transférer la requête. Si la valeur reçue est zéro (0), l'intermédiaire ne doit pas (MUST NOT) transférer la requête ; à la place, l'intermédiaire doit (MUST) répondre en tant que destinataire final. Si la valeur Max-Forwards reçue est supérieure à zéro, l'intermédiaire doit (MUST) générer un champ Max-Forwards mis à jour dans le message transféré avec une valeur de champ qui est la plus petite de a) la valeur reçue décrémentée de un (1) ou b) la valeur maximale prise en charge par le destinataire.

Un destinataire peut (MAY) ignorer un champ d'en-tête Max-Forwards reçu avec toute autre méthode de requête.

Exemple :

Max-Forwards: 10

5.2. Conditionals (Conditionnels)

Les champs d'en-tête de requête conditionnelle HTTP [RFC7232] permettent à un client de placer une condition préalable sur l'état de la ressource cible, de sorte que l'action correspondant à la sémantique de la méthode ne sera pas appliquée si la condition préalable est évaluée comme fausse. Chaque condition préalable définie par cette spécification consiste en une comparaison entre un ensemble de validateurs obtenus à partir de représentations antérieures de la ressource cible et l'état actuel des validateurs pour la représentation sélectionnée (Section 7.2 de [RFC7232]). Par conséquent, ces conditions préalables évaluent si l'état de la ressource cible a changé depuis un état donné connu du client. L'effet d'une telle évaluation dépend de la sémantique de la méthode et du choix du conditionnel, comme défini dans la Section 5 de [RFC7232].

5.3. Content Negotiation (Négociation de contenu)

Les champs d'en-tête de requête suivants peuvent être envoyés par un agent utilisateur pour s'engager dans une négociation proactive du contenu de la réponse, comme défini dans la Section 3.4.1. Les préférences envoyées dans ces champs s'appliquent à tout contenu dans la réponse, y compris les représentations de la ressource cible, les représentations d'erreur ou d'état de traitement, et potentiellement même les chaînes de texte diverses qui pourraient apparaître dans le protocole.

5.3.1. Quality Values (Valeurs de qualité)

De nombreux champs d'en-tête de requête pour la négociation proactive utilisent un paramètre commun, nommé "q" (insensible à la casse), pour attribuer un "poids" relatif à la préférence pour ce type de contenu associé. Ce poids est appelé "valeur de qualité" (ou "qvalue") car le même nom de paramètre est souvent utilisé dans les configurations de serveur pour attribuer un poids à la qualité de diverses représentations qui peuvent être sélectionnées pour une ressource.

Le poids est normalisé en un nombre réel dans la plage de 0 à 1, où 0.001 est le moins préféré et 1 est le plus préféré ; une valeur de 0 signifie "non acceptable". Si aucun paramètre "q" n'est présent, le poids par défaut est 1.

weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
       / ( "1" [ "." 0*3("0") ] )

Un expéditeur de qvalue ne doit pas (MUST NOT) générer plus de trois chiffres après la virgule. La configuration utilisateur de ces valeurs devrait être limitée de la même manière.

Exemples :

Accept: text/html;q=1, application/json;q=0.8
Accept-Language: en-US;q=0.9, fr;q=0.7

5.3.2. Accept (Accepter)

Le champ d'en-tête Accept peut être utilisé par les agents utilisateurs pour spécifier les types de médias de réponse acceptables. Les champs d'en-tête Accept peuvent être utilisés pour indiquer que la requête est spécifiquement limitée à un petit ensemble de types souhaités, comme dans le cas d'une requête pour une image en ligne.

Accept = #( media-range [ accept-params ] )

media-range    = ( "*/*"
                 / ( type "/" "*" )
                 / ( type "/" subtype )
                 ) *( OWS ";" OWS parameter )
accept-params  = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]

Le caractère astérisque "" est utilisé pour regrouper les types de médias en plages, avec "/" indiquant tous les types de médias et "type/" indiquant tous les sous-types de ce type. Le media-range peut inclure des paramètres de type de média applicables à cette plage.

Chaque media-range peut être suivi de zéro ou plusieurs paramètres de type de média applicables (par exemple, charset), d'un paramètre "q" facultatif pour indiquer un poids relatif (Section 5.3.1), puis de zéro ou plusieurs paramètres d'extension. Le paramètre "q" est nécessaire si des extensions (accept-ext) sont présentes, afin qu'elles ne soient pas confondues avec des paramètres de type de média.

L'exemple

Accept: audio/*; q=0.2, audio/basic

est interprété comme "Je préfère audio/basic, mais envoyez-moi n'importe quel type audio s'il est le meilleur disponible après une réduction de 80% de la qualité."

Un exemple plus élaboré est

Accept: text/plain; q=0.5, text/html,
        text/x-dvi; q=0.8, text/x-c

Verbalement, cela serait interprété comme "text/html et text/x-c sont les types de médias également préférés, mais s'ils n'existent pas, alors envoyez la représentation text/x-dvi, et si cela n'existe pas, envoyez la représentation text/plain."

Les plages de médias peuvent être remplacées par des plages de médias plus spécifiques ou des types de médias spécifiques. Si plusieurs plages de médias s'appliquent à un type donné, la référence la plus spécifique a la priorité. Par exemple,

Accept: text/*, text/plain, text/plain;format=flowed, */*

ont la priorité suivante :

1. text/plain;format=flowed
2. text/plain
3. text/*
4. /

Le facteur de qualité du type de média associé à un type donné est déterminé en trouvant la plage de médias avec la priorité la plus élevée qui correspond au type. Par exemple,

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
        text/html;level=2;q=0.4, */*;q=0.5

provoquerait l'association des valeurs suivantes :

Type de média	Valeur de qualité
text/html;level=1	1
text/html	0.7
text/plain	0.3
image/jpeg	0.5
text/html;level=2	0.4
text/html;level=3	0.7

Remarque : Un agent utilisateur peut être fourni avec un ensemble par défaut de valeurs de qualité pour certaines plages de médias. Cependant, à moins que l'agent utilisateur ne soit un système fermé qui ne peut pas interagir avec d'autres agents de rendu, cet ensemble par défaut devrait être configurable par l'utilisateur.

5.3.3. Accept-Charset (Accepter-Jeu de caractères)

Le champ d'en-tête Accept-Charset peut être envoyé par un agent utilisateur pour indiquer quels jeux de caractères sont acceptables dans le contenu de réponse textuel. Ce champ permet aux agents utilisateurs capables de comprendre des jeux de caractères plus complets ou à usage spécial de signaler cette capacité à un serveur d'origine capable de représenter des informations dans ces jeux de caractères.

Accept-Charset = 1#( ( charset / "*" ) [ weight ] )

Les noms de jeux de caractères sont définis dans la Section 3.1.1.2. Un agent utilisateur peut (MAY) associer une valeur de qualité à chaque jeu de caractères pour indiquer la préférence relative de l'utilisateur pour ce jeu de caractères, comme défini dans la Section 5.3.1. Un exemple est

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

La valeur spéciale "", si présente dans le champ Accept-Charset, correspond à tous les jeux de caractères qui ne sont pas mentionnés ailleurs dans le champ Accept-Charset. Si aucun "" n'est présent dans un champ Accept-Charset, alors tous les jeux de caractères non explicitement mentionnés dans le champ sont considérés comme "non acceptables" pour le client.

Une requête sans champ d'en-tête Accept-Charset implique que l'agent utilisateur acceptera n'importe quel jeu de caractères en réponse. La plupart des agents utilisateurs à usage général n'envoient pas Accept-Charset, sauf s'ils sont spécifiquement configurés pour le faire, car une liste détaillée des jeux de caractères pris en charge facilite l'identification d'un individu par un serveur en vertu de préférences inhabituelles (localisées).

Si un champ d'en-tête Accept-Charset est présent dans une requête et qu'aucune des représentations disponibles pour la réponse n'a un jeu de caractères répertorié comme acceptable, le serveur d'origine peut soit honorer le champ d'en-tête, en envoyant une réponse 406 (Not Acceptable), soit ignorer le champ d'en-tête en traitant la ressource comme si elle n'était pas soumise à la négociation de contenu.

5.3.4. Accept-Encoding (Accepter-Encodage)

Le champ d'en-tête Accept-Encoding peut être utilisé par les agents utilisateurs pour indiquer quels codages de contenu de réponse (Section 3.1.2.1) sont acceptables dans la réponse. Un jeton "identity" est utilisé comme synonyme de "pas d'encodage" afin de communiquer quand aucun encodage n'est préféré.

Accept-Encoding  = #( codings [ weight ] )
codings          = content-coding / "identity" / "*"

Chaque valeur de codings peut (MAY) recevoir une valeur de qualité associée (poids) représentant la préférence pour cet encodage, comme défini dans la Section 5.3.1. Le symbole astérisque "*" dans un champ Accept-Encoding correspond à tout codage de contenu disponible non explicitement listé dans le champ d'en-tête.

Exemples :

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Une requête sans champ d'en-tête Accept-Encoding implique que l'agent utilisateur n'a pas de préférences concernant les codages de contenu. Bien que cela permette au serveur d'utiliser n'importe quel codage de contenu dans une réponse, cela n'implique pas que l'agent utilisateur sera capable de traiter correctement tous les encodages.

Un serveur teste si un codage de contenu pour une représentation donnée est acceptable en utilisant ces règles :

1. Si aucun champ Accept-Encoding n'est dans la requête, tout codage de contenu est considéré comme acceptable par l'agent utilisateur.

2. Si la représentation n'a pas de codage de contenu, alors elle est acceptable par défaut sauf si elle est spécifiquement exclue par le champ Accept-Encoding indiquant soit "identity;q=0" soit "*;q=0" sans entrée plus spécifique pour "identity".

3. Si le codage de contenu de la représentation est l'un des codages de contenu listés dans le champ Accept-Encoding, alors il est acceptable sauf s'il est accompagné d'une qvalue de 0. (Comme défini dans la Section 5.3.1, une qvalue de 0 signifie "non acceptable".)

4. Si plusieurs codages de contenu sont acceptables, alors le codage de contenu acceptable avec la qvalue non nulle la plus élevée est préféré.

Un champ d'en-tête Accept-Encoding avec une valeur de champ combinée vide implique que l'agent utilisateur ne souhaite aucun codage de contenu en réponse. Si un champ d'en-tête Accept-Encoding est présent dans une requête et qu'aucune des représentations disponibles pour la réponse n'a un codage de contenu répertorié comme acceptable, le serveur d'origine devrait (SHOULD) envoyer une réponse sans aucun codage de contenu.

Remarque : La plupart des applications HTTP/1.0 ne reconnaissent ni n'obéissent aux qvalues associées aux codages de contenu. Cela signifie que les qvalues pourraient ne pas fonctionner et ne sont pas autorisées avec x-gzip ou x-compress.

5.3.5. Accept-Language (Accepter-Langue)

Le champ d'en-tête Accept-Language peut être utilisé par les agents utilisateurs pour indiquer l'ensemble des langues naturelles préférées dans la réponse. Les balises de langue sont définies dans la Section 3.1.3.1.

Accept-Language = 1#( language-range [ weight ] )
language-range  =
          <language-range, see [RFC4647], Section 2.1>

Chaque language-range peut recevoir une valeur de qualité associée représentant une estimation de la préférence de l'utilisateur pour les langues spécifiées par cette plage, comme défini dans la Section 5.3.1. Par exemple,

Accept-Language: da, en-gb;q=0.8, en;q=0.7

signifierait : "Je préfère le danois, mais j'accepterai l'anglais britannique et d'autres types d'anglais."

Une requête sans champ d'en-tête Accept-Language implique que l'agent utilisateur acceptera n'importe quelle langue en réponse. Si le champ d'en-tête est présent dans une requête et qu'aucune des représentations disponibles pour la réponse n'a une balise de langue correspondante, le serveur d'origine peut soit ignorer le champ d'en-tête en traitant la ressource comme si elle n'était pas soumise à la négociation de contenu, soit honorer le champ d'en-tête en envoyant une réponse 406 (Not Acceptable). Cependant, cette dernière option n'est pas encouragée, car cela peut empêcher les utilisateurs d'accéder à du contenu qu'ils pourraient être en mesure d'utiliser (avec un logiciel de traduction, par exemple).

Notez que certains destinataires traitent l'ordre dans lequel les balises de langue sont listées comme une indication de priorité décroissante, en particulier pour les balises auxquelles sont attribuées des valeurs de qualité égales (aucune valeur est la même que q=1). Cependant, ce comportement ne peut pas être compté. Pour la cohérence et pour maximiser l'interopérabilité, de nombreux agents utilisateurs attribuent des valeurs de qualité uniques à chaque balise de langue.

Une discussion supplémentaire sur les listes de priorités de langues peut être trouvée dans la Section 2.3 de [RFC4647].

5.4. Authentication Credentials (Informations d'identification d'authentification)

Deux champs d'en-tête sont utilisés pour transporter les informations d'identification d'authentification, comme défini dans l'authentification HTTP [RFC7235]. Notez que divers mécanismes personnalisés pour l'authentification des utilisateurs utilisent le champ d'en-tête Cookie à cette fin, comme défini dans [RFC6265].

5.4.1. Authorization (Autorisation)

Le champ d'en-tête Authorization permet à un agent utilisateur de s'authentifier auprès d'un serveur d'origine -- généralement, mais pas nécessairement, après avoir reçu une réponse 401 (Unauthorized). Sa valeur consiste en des informations d'identification contenant les informations d'authentification de l'agent utilisateur pour le domaine de la ressource demandée.

Authorization = credentials

Si une requête est authentifiée et qu'un domaine est spécifié, les mêmes informations d'identification sont présumées valides pour toutes les autres requêtes dans ce domaine (en supposant que le schéma d'authentification lui-même ne l'exige pas autrement, comme des informations d'identification qui varient en fonction d'une valeur de défi ou utilisant des horloges synchronisées).

Un proxy qui transfère une requête ne doit pas (MUST NOT) modifier les champs Authorization de cette requête. Voir la Section 3.2 de [RFC7235] pour plus de détails.

Pour qu'un agent utilisateur envoie des informations d'identification contenant un mot de passe, il doit savoir que la connexion au serveur d'origine est sécurisée. Voir la Section 9.4 pour les considérations de sécurité connexes.

5.4.2. Proxy-Authorization (Autorisation-Proxy)

Le champ d'en-tête Proxy-Authorization permet au client de s'identifier (ou son utilisateur) auprès d'un proxy qui nécessite une authentification. Sa valeur consiste en des informations d'identification contenant les informations d'authentification du client pour le proxy et/ou le domaine de la ressource demandée.

Proxy-Authorization = credentials

Contrairement à Authorization, le champ d'en-tête Proxy-Authorization s'applique uniquement au prochain proxy entrant qui a exigé une authentification en utilisant le champ Proxy-Authenticate. Lorsque plusieurs proxys sont utilisés dans une chaîne, le champ d'en-tête Proxy-Authorization est consommé par le premier proxy entrant qui s'attendait à recevoir des informations d'identification. Un proxy peut (MAY) relayer les informations d'identification de la requête client au proxy suivant si c'est le mécanisme par lequel les proxys authentifient de manière coopérative une requête donnée.

5.5. Request Context (Contexte de requête)

Les champs d'en-tête de requête suivants fournissent des informations supplémentaires sur le contexte de la requête, y compris des informations sur l'utilisateur, l'agent utilisateur et la ressource derrière la requête.

5.5.1. From (De)

Le champ d'en-tête From contient une adresse e-mail Internet pour un utilisateur humain qui contrôle l'agent utilisateur demandeur. L'adresse devrait être utilisable par machine, comme défini par "mailbox" dans la Section 3.4 de [RFC5322].

From = mailbox

Un exemple est :

From: [email protected]

Le champ d'en-tête From est rarement envoyé par des agents utilisateurs non robotiques. Un agent utilisateur ne devrait pas (SHOULD NOT) envoyer un champ d'en-tête From sans configuration explicite de l'utilisateur, car cela pourrait entrer en conflit avec les intérêts de confidentialité de l'utilisateur ou la politique de sécurité de son site.

Un agent utilisateur robotique devrait (SHOULD) envoyer un champ d'en-tête From valide afin que la personne responsable de l'exécution du robot puisse être contactée si des problèmes surviennent sur les serveurs, par exemple si le robot envoie des requêtes excessives, non désirées ou invalides.

Un serveur ne devrait pas (SHOULD NOT) utiliser le champ d'en-tête From pour le contrôle d'accès ou l'authentification, car la plupart des destinataires supposeront que la valeur du champ est une information publique.

5.5.2. Referer (Référent)

Le champ d'en-tête Referer [sic] permet à l'agent utilisateur de spécifier une référence URI pour la ressource à partir de laquelle l'URI cible a été obtenue (c'est-à-dire, le "référent", bien que le nom du champ soit mal orthographié). Un agent utilisateur ne doit pas (MUST NOT) inclure les composants fragment et userinfo de la référence URI [RFC3986], le cas échéant, lors de la génération de la valeur du champ Referer.

Referer = absolute-URI / partial-URI

Le champ d'en-tête Referer permet aux serveurs de générer des liens retour vers d'autres ressources pour une analyse simple, la journalisation, la mise en cache optimisée, etc. Il permet également de trouver des liens obsolètes ou mal saisis pour la maintenance. Certains serveurs utilisent le champ d'en-tête Referer comme moyen de refuser des liens provenant d'autres sites (appelés "liens profonds") ou de restreindre la falsification de requête intersite (CSRF), mais toutes les requêtes ne le contiennent pas.

Exemple :

Referer: http://www.example.org/hypertext/Overview.html

Si l'URI cible a été obtenue d'une source qui n'a pas sa propre URI (par exemple, entrée du clavier de l'utilisateur ou une entrée dans les signets/favoris de l'utilisateur), l'agent utilisateur doit (MUST) soit exclure le champ Referer, soit l'envoyer avec une valeur de "about:blank".

Le champ Referer a le potentiel de révéler des informations sur le contexte de la requête ou l'historique de navigation de l'utilisateur, ce qui est une préoccupation de confidentialité si l'identificateur de la ressource référente révèle des informations personnelles (comme un nom de compte) ou une ressource qui est censée être confidentielle (comme derrière un pare-feu ou interne à un service sécurisé). La plupart des agents utilisateurs à usage général n'envoient pas le champ d'en-tête Referer lorsque la ressource référente est un URI local "file" ou "data". Un agent utilisateur ne doit pas (MUST NOT) envoyer un champ d'en-tête Referer dans une requête HTTP non sécurisée si la page référente a été reçue avec un protocole sécurisé. Voir la Section 9.4 pour des considérations de sécurité supplémentaires.

Certains intermédiaires sont connus pour supprimer de manière indiscriminée les champs d'en-tête Referer des requêtes sortantes. Cela a l'effet secondaire malheureux d'interférer avec la protection contre les attaques CSRF, qui peuvent être beaucoup plus préjudiciables pour leurs utilisateurs. Les intermédiaires et les extensions d'agent utilisateur qui souhaitent limiter la divulgation d'informations dans Referer devraient restreindre leurs modifications à des modifications spécifiques, telles que le remplacement des noms de domaine internes par des pseudonymes ou la troncature des composants de requête et/ou de chemin. Un intermédiaire ne devrait pas (SHOULD NOT) modifier ou supprimer le champ d'en-tête Referer lorsque la valeur du champ partage le même schéma et hôte que la cible de la requête.

5.5.3. TE (Encodage de transfert)

Le champ d'en-tête TE indique quels codages de transfert, en plus de chunked, le client est prêt à accepter en réponse, et si le client est prêt à accepter des champs de remorque dans un codage de transfert chunked.

La valeur de champ TE consiste en une liste de noms de codage de transfert séparés par des virgules, chacun permettant des paramètres facultatifs (comme décrit dans la Section 4 de [RFC7230]), et/ou le mot-clé "trailers".

TE        = #( t-codings )
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank      = ( "0" [ "." 0*3DIGIT ] )
          / ( "1" [ "." 0*3("0") ] )

Trois exemples d'utilisation de TE sont ci-dessous.

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Le champ d'en-tête TE s'applique uniquement à la connexion immédiate. Par conséquent, le mot-clé "TE" doit (MUST) être fourni dans un champ d'en-tête Connection (Section 6.1 de [RFC7230]) chaque fois que TE est présent dans un message HTTP/1.1.

Un serveur teste si un codage de transfert est acceptable en utilisant les mêmes règles que pour Accept-Encoding (Section 5.3.4), sauf que l'encodage nommé "trailers" est toujours acceptable et qu'un codage de transfert avec une valeur de paramètre "q" de 0 n'est pas acceptable.

Étant donné que le champ d'en-tête TE s'applique uniquement à la connexion immédiate, un expéditeur de TE doit (MUST) également envoyer une option de connexion "TE" dans le champ d'en-tête Connection (Section 6.1 de [RFC7230]) afin d'empêcher le champ TE d'être transféré par des intermédiaires qui ne prennent pas en charge sa sémantique.

5.5.4. User-Agent (Agent utilisateur)

Le champ d'en-tête User-Agent contient des informations sur l'agent utilisateur à l'origine de la requête, qui est souvent utilisé par les serveurs pour aider à identifier la portée des problèmes d'interopérabilité signalés, pour contourner ou adapter les réponses afin d'éviter certaines limitations d'agent utilisateur particulières, et pour les analyses concernant l'utilisation du navigateur ou du système d'exploitation. Un agent utilisateur devrait (SHOULD) envoyer un champ User-Agent dans chaque requête, sauf s'il est spécifiquement configuré pour ne pas le faire.

User-Agent = product *( RWS ( product / comment ) )

La valeur de champ User-Agent consiste en un ou plusieurs identificateurs de produit, chacun suivi de zéro ou plusieurs commentaires (Section 3.2 de [RFC7230]), qui ensemble identifient le logiciel de l'agent utilisateur et ses sous-produits significatifs. Par convention, les identificateurs de produit sont listés par ordre décroissant de leur importance pour identifier le logiciel de l'agent utilisateur. Chaque identificateur de produit consiste en un nom et une version facultative, comme défini dans la Section 5.5.3 de [RFC7230].

Exemple :

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Un agent utilisateur ne devrait pas (SHOULD NOT) générer un champ User-Agent contenant des détails inutilement fins et devrait (SHOULD) limiter l'ajout de sous-produits par des tiers. Des valeurs de champ User-Agent trop longues et détaillées augmentent la latence de la requête et le risque qu'un utilisateur soit identifié contre sa volonté ("empreinte digitale").

De même, les implémentations sont encouragées à ne pas utiliser les jetons de produit d'autres implémentations afin de déclarer la compatibilité avec elles, car cela contourne le but du champ. Si un agent utilisateur se fait passer pour un agent utilisateur différent, les destinataires peuvent supposer que l'utilisateur souhaite intentionnellement voir des réponses adaptées à cet agent utilisateur identifié, même si elles pourraient ne pas fonctionner aussi bien pour l'agent utilisateur réel utilisé.

---