12. Négociation de Contenu (Content Negotiation)

Lorsque les réponses transmettent du contenu, qu'elles indiquent un succès ou une erreur, le serveur d'origine dispose souvent de différentes façons de représenter ces informations ; par exemple, dans différents formats, langues ou encodages. De même, différents utilisateurs ou agents utilisateurs peuvent avoir des capacités, des caractéristiques ou des préférences différentes qui pourraient influencer quelle représentation, parmi celles disponibles, serait la meilleure à livrer. Pour cette raison, HTTP fournit des mécanismes de négociation de contenu.

Cette spécification définit trois modèles de négociation de contenu rendus visibles dans le protocole : la négociation « proactive », où le serveur sélectionne la représentation en fonction des préférences déclarées de l'agent utilisateur ; la négociation « réactive », où le serveur fournit une liste de représentations parmi lesquelles l'agent utilisateur peut choisir ; et la négociation de « contenu de requête », où l'agent utilisateur sélectionne la représentation pour une requête future en fonction des préférences déclarées par le serveur dans une réponse passée.

D'autres modèles de négociation de contenu incluent le « contenu conditionnel », où la représentation se compose de plusieurs parties qui sont rendues sélectivement en fonction des paramètres de l'agent utilisateur ; le « contenu actif », où la représentation contient un script qui effectue des requêtes supplémentaires (plus spécifiques) en fonction des caractéristiques de l'agent utilisateur ; et la « Négociation de Contenu Transparente » ([RFC2295]), où la sélection de contenu est effectuée par un intermédiaire. Ces modèles ne sont pas mutuellement exclusifs, et chacun présente des compromis en termes d'applicabilité et de praticité.

Notez que, dans tous les cas, HTTP n'est pas conscient de la sémantique des ressources. La cohérence avec laquelle un serveur d'origine répond aux requêtes, au fil du temps et pour des clients disparates, et donc la « similitude » des représentations observées d'une ressource au fil du temps, est entièrement déterminée par l'entité ou l'algorithme qui sélectionne ou génère ces réponses.

12.1. Négociation Proactive (Proactive Negotiation)

Lorsque les préférences de négociation de contenu sont envoyées par l'agent utilisateur dans une requête pour encourager un algorithme situé sur le serveur à sélectionner la représentation préférée, cela s'appelle la « négociation proactive » (aussi appelée « négociation pilotée par le serveur »). La sélection est basée sur les représentations disponibles de la réponse (les dimensions sur lesquelles elle pourrait varier, telles que la langue, l'encodage du contenu, etc.) comparées à diverses informations fournies dans la requête, y compris les champs de négociation explicites ci-dessous et les caractéristiques implicites, telles que l'adresse réseau du client ou des parties du champ User-Agent.

La négociation proactive est avantageuse lorsque l'algorithme de sélection parmi les représentations disponibles est difficile à décrire à un agent utilisateur, ou lorsque le serveur souhaite envoyer sa « meilleure estimation » à l'agent utilisateur avec la première réponse (espérant éviter le délai d'aller-retour d'une requête ultérieure si cette « meilleure estimation » est suffisamment bonne pour l'utilisateur). Afin d'améliorer l'estimation du serveur, un agent utilisateur PEUT (MAY) envoyer des champs d'en-tête de requête décrivant ses préférences.

La négociation proactive présente de sérieux inconvénients :

• Il est impossible pour le serveur de déterminer avec précision ce qui pourrait être « le meilleur » pour un utilisateur donné, car cela nécessiterait une connaissance complète des capacités de l'agent utilisateur et de l'utilisation prévue de la réponse (par exemple, l'utilisateur veut-il la voir à l'écran ou l'imprimer sur papier ?) ;

• Demander à l'agent utilisateur de décrire ses capacités dans chaque requête peut être à la fois très inefficace (étant donné que seul un faible pourcentage de réponses ont plusieurs représentations) et un risque potentiel pour la vie privée de l'utilisateur ;

• Cela complique l'implémentation d'un serveur d'origine et les algorithmes de génération de réponses à une requête ; et,

• Cela limite la réutilisabilité des réponses pour la mise en cache partagée.

Un agent utilisateur ne peut pas compter sur le respect cohérent des préférences de négociation proactive, car le serveur d'origine pourrait ne pas implémenter la négociation proactive pour la ressource demandée ou pourrait décider qu'envoyer une réponse qui ne se conforme pas aux préférences de l'agent utilisateur est préférable à envoyer une réponse 406 (Not Acceptable).

Un champ d'en-tête Vary (Section 12.5.5) est souvent envoyé dans les réponses soumises à la négociation proactive pour indiquer quelles parties des informations de requête ont été utilisées dans l'algorithme de sélection.

Les champs d'en-tête de requête Accept, Accept-Charset, Accept-Encoding et Accept-Language sont définis ci-dessous pour qu'un agent utilisateur s'engage dans la négociation proactive du contenu de la réponse. Les préférences envoyées dans ces champs s'appliquent à tout contenu de 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 diverses chaînes de texte qui pourraient apparaître dans le protocole.

12.2. Négociation Réactive (Reactive Negotiation)

Avec la « négociation réactive » (aussi appelée « négociation pilotée par l'agent »), la sélection du contenu (quel que soit le code d'état) est effectuée par l'agent utilisateur après avoir reçu une réponse initiale. Le mécanisme de négociation réactive peut être aussi simple qu'une liste de références à des représentations alternatives.

Si l'agent utilisateur n'est pas satisfait du contenu de la réponse initiale, il peut effectuer une requête GET sur une ou plusieurs des ressources alternatives pour obtenir une représentation différente. La sélection de telles alternatives peut être effectuée automatiquement (par l'agent utilisateur) ou manuellement (par exemple, par l'utilisateur sélectionnant dans un menu hypertexte).

Un serveur peut choisir de ne pas envoyer de représentation initiale, autre que la liste des alternatives, et ainsi indiquer que la négociation réactive par l'agent utilisateur est préférée. Par exemple, les alternatives listées dans les réponses avec les codes d'état 300 (Multiple Choices) et 406 (Not Acceptable) incluent des informations sur les représentations disponibles afin que l'utilisateur ou l'agent utilisateur puisse réagir en faisant une sélection.

La négociation réactive est avantageuse lorsque la réponse varierait sur des dimensions couramment utilisées (telles que le type, la langue ou l'encodage), lorsque le serveur d'origine est incapable de déterminer les capacités d'un agent utilisateur en examinant la requête, et généralement lorsque les caches publics sont utilisés pour distribuer la charge du serveur et réduire l'utilisation du réseau.

La négociation réactive souffre des inconvénients de transmettre une liste d'alternatives à l'agent utilisateur, ce qui dégrade la latence perçue par l'utilisateur si elle est transmise dans la section d'en-tête, et nécessite une deuxième requête pour obtenir une représentation alternative. De plus, cette spécification ne définit pas de mécanisme pour prendre en charge la sélection automatique, bien qu'elle n'empêche pas le développement d'un tel mécanisme.

12.3. Négociation de Contenu de Requête (Request Content Negotiation)

Lorsque les préférences de négociation de contenu sont envoyées par un serveur dans une réponse, les préférences listées sont appelées « négociation de contenu de requête » car elles visent à influencer la sélection d'un contenu approprié pour les requêtes ultérieures à cette ressource. Par exemple, les champs d'en-tête Accept (Section 12.5.1) et Accept-Encoding (Section 12.5.3) peuvent être envoyés dans une réponse pour indiquer les types de médias et les encodages de contenu préférés pour les requêtes ultérieures à cette ressource.

De même, la Section 3.1 de [RFC5789] définit le champ d'en-tête de réponse « Accept-Patch », qui permet de découvrir quels types de contenu sont acceptés dans les requêtes PATCH.

12.4. Caractéristiques des Champs de Négociation de Contenu (Content Negotiation Field Features)

12.4.1. Absence (Absence)

Pour chacun des champs de négociation de contenu, une requête qui n'inclut pas ce champ implique que l'expéditeur n'a aucune préférence sur cette dimension de négociation.

Si un champ d'en-tête de négociation de contenu est présent dans une requête et qu'aucune des représentations disponibles pour la réponse ne peut être considérée comme acceptable selon celui-ci, 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 réponse comme si elle n'était pas soumise à la négociation de contenu pour ce champ d'en-tête de requête. Cependant, cela n'implique pas que le client sera capable d'utiliser la représentation.

Note : Un agent utilisateur envoyant ces champs d'en-tête facilite pour un serveur l'identification d'un individu en vertu des caractéristiques de requête de l'agent utilisateur (Section 17.13).

12.4.2. Valeurs de Qualité (Quality Values)

Les champs de négociation de contenu définis par cette spécification 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é une « 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é relative des diverses représentations pouvant être sélectionnées pour une ressource.

Le poids est normalisé à 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.

12.4.3. Valeurs Joker (Wildcard Values)

La plupart de ces champs d'en-tête, lorsque indiqué, définissent une valeur joker (*) pour sélectionner les valeurs non spécifiées. Si aucun joker n'est présent, les valeurs non explicitement mentionnées dans le champ sont considérées comme inacceptables. Dans Vary, une valeur joker signifie que la variance est illimitée.

Note : En pratique, l'utilisation de jokers dans la négociation de contenu a une valeur pratique limitée, car il est rarement utile de dire, par exemple, « Je préfère image/* plus ou moins que (une autre valeur spécifique) ». En envoyant Accept: */*;q=0, les clients peuvent explicitement demander une réponse 406 (Not Acceptable) si un format plus préféré n'est pas disponible, mais ils doivent toujours être capables de gérer une réponse différente, car le serveur est autorisé à ignorer leur préférence.

12.5. Champs de Négociation de Contenu (Content Negotiation Fields)

12.5.1. Accept

Le champ d'en-tête « Accept » peut être utilisé par les agents utilisateurs pour spécifier leurs préférences concernant les types de médias de réponse. Par exemple, le champ d'en-tête Accept peut être utilisé 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.

Lorsqu'il est envoyé par un serveur dans une réponse, Accept fournit des informations sur les types de contenu préférés dans le contenu d'une requête ultérieure à la même ressource.

Accept = #( media-range [ weight ] )

media-range    = ( "*/*"
                   / ( type "/" "*" )
                   / ( type "/" subtype )
                 ) parameters

Le caractère astérisque * est utilisé pour regrouper les types de médias en plages, */* 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 paramètres de type de média applicables optionnels (par exemple, charset), suivis d'un paramètre « q » optionnel pour indiquer un poids relatif (Section 12.4.2).

Les spécifications précédentes permettaient l'apparition de paramètres d'extension supplémentaires après le paramètre de poids. La syntaxe accept-ext (accept-params, accept-ext) a été supprimée car elle avait une définition complexe, n'était pas utilisée en pratique, et est plus facilement déployée via de nouveaux champs d'en-tête. Les expéditeurs utilisant des poids DEVRAIENT (SHOULD) envoyer « q » en dernier (après tous les paramètres media-range). Les destinataires DEVRAIENT (SHOULD) traiter tout paramètre nommé « q » comme un poids, quel que soit l'ordre des paramètres.

Note : L'utilisation du nom de paramètre « q » pour contrôler la négociation de contenu interférerait avec tout paramètre de type de média portant le même nom. Par conséquent, les enregistrements de types de médias interdisent les paramètres nommés « q ».

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 qualité de 80% ».

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 celle-ci n'existe pas non plus, 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 plus d'une plage de médias s'applique à 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 plus haute priorité qui correspond au type. Par exemple :

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
       text/plain;format=fixed;q=0.4, */*;q=0.5

entraînerait l'association des valeurs suivantes :

Type de Média	Valeur de Qualité
text/plain;format=flowed	1
text/plain	0.7
text/html	0.3
image/jpeg	0.5
text/plain;format=fixed	0.4
text/html;level=3	0.7

Note : Un agent utilisateur peut se voir fournir un ensemble de valeurs de qualité par défaut 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.

12.5.2. Accept-Charset

Le champ d'en-tête « Accept-Charset » peut être envoyé par un agent utilisateur pour indiquer ses préférences pour les jeux de caractères dans le contenu de réponse textuel. Par exemple, 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 = #( ( token / "*" ) [ weight ] )

Les noms de jeux de caractères sont définis dans la Section 8.3.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 12.4.2. Un exemple est :

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

La valeur spéciale *, si elle est présente dans le champ d'en-tête Accept-Charset, correspond à chaque jeu de caractères non mentionné ailleurs dans le champ.

Note : Accept-Charset est déprécié car UTF-8 est devenu presque omniprésent et l'envoi d'une liste détaillée de jeux de caractères préférés par l'utilisateur gaspille de la bande passante, augmente la latence et facilite beaucoup trop l'empreinte digitale passive (Section 17.13). La plupart des agents utilisateurs généralistes n'envoient pas Accept-Charset sauf s'ils sont spécifiquement configurés pour le faire.

12.5.3. Accept-Encoding

Le champ d'en-tête « Accept-Encoding » peut être utilisé pour indiquer des préférences concernant l'utilisation d'encodages de contenu (Section 8.4.1).

Lorsqu'il est envoyé par un agent utilisateur dans une requête, Accept-Encoding indique les encodages de contenu acceptables dans une réponse.

Lorsqu'il est envoyé par un serveur dans une réponse, Accept-Encoding fournit des informations sur les encodages de contenu préférés dans le contenu d'une requête ultérieure à la même ressource.

Le jeton « identity » est utilisé comme synonyme de « sans encodage » afin de communiquer lorsqu'aucun encodage n'est préféré.

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

Chaque valeur de codings PEUT (MAY) se voir attribuer une valeur de qualité associée (poids) représentant la préférence pour cet encodage, comme défini dans la Section 12.4.2. Le symbole astérisque * dans un champ Accept-Encoding correspond à tout encodage de contenu disponible non explicitement listé dans le champ.

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

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

1. Si aucun champ d'en-tête Accept-Encoding n'est dans la requête, l'agent utilisateur considère que tout encodage de contenu est acceptable.

2. Si la représentation n'a pas d'encodage de contenu, alors elle est acceptable par défaut sauf si le champ d'en-tête Accept-Encoding l'exclut explicitement, en déclarant soit identity;q=0 soit *;q=0 sans entrée « identity » plus spécifique.

3. Si l'encodage de contenu de la représentation est l'un des encodages de contenu listés dans la valeur du champ Accept-Encoding, alors il est acceptable sauf s'il est accompagné d'une qvalue de 0. (Comme défini dans la Section 12.4.2, une qvalue de 0 signifie « non acceptable ».)

Une représentation peut être encodée avec plusieurs encodages de contenu. Cependant, la plupart des encodages de contenu sont des moyens alternatifs d'accomplir le même objectif (par exemple, la compression de données). Lors de la sélection entre plusieurs encodages de contenu ayant le même objectif, l'encodage 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 vide implique que l'agent utilisateur ne souhaite aucun encodage de contenu en réponse. Si un champ d'en-tête Accept-Encoding non vide est présent dans une requête et qu'aucune des représentations disponibles pour la réponse n'a un encodage de contenu listé comme acceptable, le serveur d'origine DEVRAIT (SHOULD) envoyer une réponse sans aucun encodage de contenu à moins que l'encodage identity ne soit indiqué comme inacceptable.

Lorsque le champ d'en-tête Accept-Encoding est présent dans une réponse, il indique quels encodages de contenu la ressource était disposée à accepter dans la requête associée. La valeur du champ est évaluée de la même manière que dans une requête.

Notez que cette information est spécifique à la requête associée ; l'ensemble des encodages pris en charge peut être différent pour d'autres ressources sur le même serveur et pourrait changer au fil du temps ou dépendre d'autres aspects de la requête (tels que la méthode de requête).

Un serveur qui échoue une requête en raison d'un encodage de contenu non pris en charge devrait répondre avec un statut 415 (Unsupported Media Type) et inclure un champ d'en-tête Accept-Encoding dans cette réponse, permettant aux clients de distinguer les problèmes liés aux encodages de contenu et aux types de médias. Afin d'éviter toute confusion avec les problèmes liés aux types de médias, un serveur qui échoue une requête avec un statut 415 pour des raisons non liées à l'encodage de contenu NE DOIT PAS (MUST NOT) inclure le champ d'en-tête Accept-Encoding.

L'utilisation la plus courante d'Accept-Encoding est dans les réponses avec un code d'état 415 (Unsupported Media Type), en réponse à l'utilisation optimiste d'un encodage de contenu par les clients. Cependant, le champ d'en-tête peut également être utilisé pour indiquer aux clients que les encodages de contenu sont pris en charge, afin d'optimiser les interactions futures. Par exemple, une ressource pourrait l'inclure dans une réponse 2xx (Successful) lorsque le contenu de la requête aurait pu être encodé, mais que le client n'a pas utilisé d'encodage de contenu.

12.5.4. Accept-Language

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 8.5.1.

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

Chaque language-range peut se voir attribuer 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 12.4.2. 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 ».

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 identique à q=1). Cependant, on ne peut pas compter sur ce comportement. Pour la cohérence et pour maximiser l'interopérabilité, de nombreux agents utilisateurs attribuent à chaque balise de langue une valeur de qualité unique tout en les listant également par ordre de qualité décroissante. Des discussions supplémentaires sur les listes de priorité de langue peuvent être trouvées dans la Section 2.3 de [RFC4647].

Pour la correspondance, la Section 3 de [RFC4647] définit plusieurs schémas de correspondance. Les implémentations peuvent offrir le schéma de correspondance le plus approprié à leurs besoins. Le schéma de « Filtrage de Base » ([RFC4647], Section 3.3.1) est identique au schéma de correspondance qui a été précédemment défini pour HTTP dans la Section 14.4 de [RFC2616].

L'envoi d'un champ d'en-tête Accept-Language avec les préférences linguistiques complètes de l'utilisateur dans chaque requête peut être contraire aux attentes de confidentialité de l'utilisateur (Section 17.13).

Étant donné que l'intelligibilité dépend fortement de l'utilisateur individuel, les agents utilisateurs doivent permettre un contrôle utilisateur sur les préférences linguistiques (soit par la configuration de l'agent utilisateur lui-même, soit en se conformant par défaut à un paramètre système contrôlable par l'utilisateur). Un agent utilisateur qui ne fournit pas un tel contrôle NE DOIT PAS (MUST NOT) envoyer de champ d'en-tête Accept-Language.

Note : Les agents utilisateurs devraient fournir des conseils aux utilisateurs lors de la définition d'une préférence, car les utilisateurs sont rarement familiers avec les détails de la correspondance de langue tels que décrits ci-dessus. Par exemple, les utilisateurs pourraient supposer qu'en sélectionnant « en-gb », ils recevront tout type de document anglais si l'anglais britannique n'est pas disponible. Un agent utilisateur pourrait suggérer, dans un tel cas, d'ajouter « en » à la liste pour un meilleur comportement de correspondance.

12.5.5. Vary

Le champ d'en-tête « Vary » dans une réponse décrit quelles parties d'un message de requête, en dehors de la méthode et de l'URI cible, auraient pu influencer le processus du serveur d'origine pour sélectionner le contenu de cette réponse.

Vary = #( "*" / field-name )

Une valeur de champ Vary est soit le membre joker *, soit une liste de jetons field-name de requête, appelés les champs d'en-tête de sélection, qui auraient pu jouer un rôle dans la sélection de la représentation pour cette réponse. Les champs d'en-tête de sélection potentiels ne sont pas limités aux champs définis par cette spécification.

Une liste contenant le membre * signale que d'autres aspects de la requête auraient pu jouer un rôle dans la sélection de la représentation de réponse, y compris éventuellement des aspects en dehors de la syntaxe du message (par exemple, l'adresse réseau du client). Un destinataire ne pourra pas déterminer si cette réponse est appropriée pour une requête ultérieure sans transférer la requête au serveur d'origine. Un proxy NE DOIT PAS (MUST NOT) générer un * dans une valeur de champ Vary.

Par exemple, une réponse qui contient :

Vary: accept-encoding, accept-language

indique que le serveur d'origine pourrait avoir utilisé les champs d'en-tête Accept-Encoding et Accept-Language de la requête (ou leur absence) comme facteurs déterminants lors du choix du contenu pour cette réponse.

Un champ Vary contenant une liste de noms de champs a deux objectifs :

1. Informer les destinataires du cache qu'ils NE DOIVENT PAS (MUST NOT) utiliser cette réponse pour satisfaire une requête ultérieure à moins que la requête ultérieure n'ait les mêmes valeurs pour les champs d'en-tête listés que la requête d'origine (voir Section 4.1 de [CACHING]) ou que la réutilisation de la réponse ait été validée par le serveur d'origine. En d'autres termes, Vary étend la clé de cache requise pour faire correspondre une nouvelle requête à l'entrée de cache stockée.

2. Informer les destinataires agents utilisateurs que cette réponse était sujette à la négociation de contenu (Section 12) et qu'une représentation différente pourrait être envoyée dans une requête ultérieure si des valeurs supplémentaires sont fournies dans les champs d'en-tête listés (négociation proactive).

Un serveur d'origine DEVRAIT (SHOULD) générer un champ d'en-tête Vary sur une réponse pouvant être mise en cache lorsqu'il souhaite que la réponse soit sélectivement réutilisée pour les requêtes ultérieures à cette ressource. Généralement, c'est le cas lorsque le contenu de la réponse a été adapté pour mieux correspondre aux préférences exprimées par ces champs d'en-tête de sélection, comme lorsqu'un serveur d'origine a sélectionné la langue de la réponse en fonction du champ d'en-tête Accept-Language de la requête.

Vary peut être omis lorsqu'un serveur d'origine considère que la variance dans la sélection de contenu est moins significative que l'impact de Vary sur les performances de mise en cache, en particulier lorsque la réutilisation est déjà limitée par les directives de réponse de cache (voir Section 5.2 de [CACHING]).

Il n'est pas nécessaire d'envoyer le nom de champ Authorization dans Vary car la réutilisation de cette réponse pour un utilisateur différent est interdite par la définition du champ (Section 11.6.2). De même, si le contenu de la réponse a été sélectionné ou influencé par la région du réseau, mais que le serveur d'origine souhaite que la réponse mise en cache soit réutilisée même si le destinataire passe d'une région à une autre, alors il n'est pas nécessaire pour le serveur d'origine d'indiquer cette variance dans Vary.