3. Representations (Représentations)

Considérant qu'une ressource peut être n'importe quoi, et que l'interface uniforme fournie par HTTP est similaire à une fenêtre à travers laquelle on ne peut observer et agir sur une telle chose que par la communication de messages à un acteur indépendant de l'autre côté, une abstraction est nécessaire pour "représenter" (prendre la place de) l'état actuel ou souhaité de cette chose dans nos communications. Cette abstraction s'appelle une représentation (representation) [REST].

Aux fins de HTTP, une "représentation" (representation) est une information qui vise à refléter l'état passé, actuel ou souhaité d'une ressource donnée, dans un format qui peut être facilement communiqué via le protocole, et qui se compose d'un ensemble de métadonnées de représentation et d'un flux potentiellement illimité de données de représentation.

Un serveur d'origine (origin server) peut être doté ou capable de générer plusieurs représentations destinées chacune à refléter l'état actuel d'une ressource cible. Dans de tels cas, un algorithme est utilisé par le serveur d'origine pour sélectionner l'une de ces représentations comme la plus applicable à une requête donnée, généralement basée sur la négociation de contenu (content negotiation). Cette "représentation sélectionnée" (selected representation) est utilisée pour fournir les données et métadonnées nécessaires à l'évaluation des requêtes conditionnelles [RFC7232] et à la construction de la charge utile pour les réponses 200 (OK) et 304 (Not Modified) à GET [Section 4.3.1].

3.1. Representation Metadata (Métadonnées de représentation)

Les champs d'en-tête de représentation (representation header fields) fournissent des métadonnées sur la représentation. Lorsqu'un message inclut un corps de charge utile (payload body), les champs d'en-tête de représentation décrivent comment interpréter les données de représentation enfermées dans le corps de charge utile. Dans une réponse à une requête HEAD, les champs d'en-tête de représentation décrivent les données de représentation qui auraient été enfermées dans le corps de charge utile si la même requête avait été une requête GET.

3.1.1. Processing Representation Data (Traitement des données de représentation)

Le but des métadonnées de représentation est de permettre aux destinataires de savoir avec quel format ils ont affaire, quelle langue ou quelles langues la représentation utilise, et quelles transformations ont été appliquées aux données de représentation par les intermédiaires intervenants.

3.1.1.1. Media Type (Type de média)

HTTP utilise les types de médias Internet [RFC2046] dans les champs d'en-tête Content-Type (Section 3.1.1.5) et Accept (Section 5.3.2) afin de fournir un typage de données ouvert et extensible et une négociation de types. Les types de médias définissent à la fois un format de données et divers modèles de traitement : comment traiter ces données conformément à chaque contexte dans lequel elles sont reçues.

media-type = type "/" subtype *( OWS ";" OWS parameter )
type       = token
subtype    = token

Le type/sous-type peut être suivi de paramètres sous forme de paires nom=valeur.

parameter      = token "=" ( token / quoted-string )

Les jetons de type, sous-type et nom de paramètre ne sont pas sensibles à la casse. Les valeurs de paramètres peuvent être sensibles à la casse ou non, selon la sémantique du nom du paramètre. La présence ou l'absence d'un paramètre peut être significative pour le traitement d'un type de média, selon sa définition dans le registre des types de médias.

Une valeur de paramètre qui correspond à la production de jeton peut être transmise soit en tant que jeton, soit dans une chaîne entre guillemets. Les valeurs entre guillemets et sans guillemets sont équivalentes. Par exemple, les exemples suivants sont tous équivalents, mais le premier est préféré pour la cohérence :

text/html;charset=utf-8
text/html;charset=UTF-8
text/HTML;charset="utf-8"
text/html; charset="utf-8"

Les types de médias Internet doivent être enregistrés auprès de l'IANA conformément aux procédures définies dans [BCP13].

3.1.1.2. Charset (Jeu de caractères)

HTTP utilise des noms de jeux de caractères pour indiquer ou négocier le schéma d'encodage de caractères d'une représentation textuelle [RFC6365]. Un jeu de caractères est identifié par un jeton insensible à la casse.

charset = token

Les noms de jeux de caractères doivent être enregistrés dans le registre IANA "Character Sets" (http://www.iana.org/assignments/character-sets) conformément aux procédures définies dans [RFC2978].

3.1.1.3. Canonicalization and Text Defaults (Canonisation et valeurs par défaut du texte)

Les types de médias Internet sont enregistrés avec une forme canonique afin d'être interopérables entre les systèmes ayant des formats d'encodage natifs différents. Les représentations sélectionnées ou transférées via HTTP devraient être sous forme canonique, pour bon nombre des mêmes raisons décrites par les extensions multimédia de messagerie Internet (Multipurpose Internet Mail Extensions, MIME) [RFC2045]. Cependant, les caractéristiques de performance des déploiements de messagerie électronique (c'est-à-dire, stocker et transférer des messages vers des pairs) sont sensiblement différentes de celles communes à HTTP et au Web (services d'information basés sur serveur). De plus, les contraintes de MIME pour des raisons de compatibilité avec les protocoles de transfert de courrier plus anciens ne s'appliquent pas à HTTP (voir l'Annexe A).

La forme canonique de MIME exige que les sous-types de médias du type "text" utilisent CRLF comme saut de ligne de texte. HTTP permet le transfert de médias textuels avec un simple CR ou LF représentant un saut de ligne, lorsque de tels sauts de ligne sont cohérents pour une représentation entière. Un expéditeur HTTP peut générer (MAY), et un destinataire doit être capable d'analyser (MUST), des sauts de ligne dans des médias textuels constitués de CRLF, CR nu ou LF nu. De plus, les médias textuels en HTTP ne sont pas limités aux jeux de caractères qui utilisent les octets 13 et 10 pour CR et LF, respectivement. Cette flexibilité concernant les sauts de ligne ne s'applique qu'au texte dans une représentation qui s'est vu attribuer un type de média "text" ; elle ne s'applique pas aux types "multipart" ou aux éléments HTTP en dehors du corps de charge utile (par exemple, les champs d'en-tête).

Si une représentation est encodée avec un codage de contenu (content-coding), les données sous-jacentes devraient être dans une forme définie ci-dessus avant d'être encodées.

3.1.1.4. Multipart Types (Types multipartites)

MIME fournit un certain nombre de types "multipart" - des encapsulations d'une ou plusieurs représentations au sein d'un seul corps de message. Tous les types multipartites partagent une syntaxe commune, telle que définie dans la Section 5.1.1 de [RFC2046], et incluent un paramètre de frontière dans la valeur du type de média. Le corps du message est lui-même un élément de protocole ; un expéditeur doit générer (MUST) uniquement CRLF pour représenter les sauts de ligne entre les parties du corps.

Le cadrage de message HTTP n'utilise pas la frontière multipartite comme indicateur de longueur du corps du message, bien qu'elle puisse être utilisée par des implémentations qui génèrent ou traitent la charge utile. Par exemple, le type "multipart/byteranges" est défini par HTTP pour une utilisation dans certaines réponses 206 (Partial Content) [RFC7233].

3.1.1.5. Content-Type (Type de contenu)

Le champ d'en-tête Content-Type indique le type de média de la représentation associée : soit la représentation enfermée dans la charge utile du message, soit la représentation sélectionnée, tel que déterminé par la sémantique du message. Le type de média indiqué définit à la fois le format de données et la façon dont ces données doivent être traitées par un destinataire, dans le cadre de la sémantique du message reçu, après le décodage de tout codage de contenu indiqué par Content-Encoding.

Content-Type = media-type

Les types de médias sont définis dans la Section 3.1.1.1. Un exemple du champ est :

Content-Type: text/html; charset=ISO-8859-4

Un expéditeur qui génère un message contenant un corps de charge utile devrait générer (SHOULD) un champ d'en-tête Content-Type dans ce message, sauf si le type de média prévu de la représentation enfermée est inconnu de l'expéditeur. Si un champ d'en-tête Content-Type n'est pas présent, le destinataire peut (MAY) soit supposer un type de média de "application/octet-stream" ([RFC2046] Section 4.5.1), soit examiner les données pour déterminer leur type.

En pratique, les propriétaires de ressources ne configurent pas toujours correctement leur serveur d'origine pour fournir le Content-Type correct pour une représentation donnée, avec pour résultat que certains clients examinent le contenu de la charge utile et remplacent le type spécifié. Les clients qui le font risquent de tirer des conclusions incorrectes, ce qui pourrait exposer à des risques de sécurité supplémentaires (par exemple, "escalade de privilèges"). De plus, il est impossible de déterminer l'intention de l'expéditeur en examinant le format des données : de nombreux formats de données correspondent à plusieurs types de médias qui ne diffèrent que par la sémantique de traitement. Il est encouragé aux implémenteurs de fournir un moyen de désactiver ce "reniflage de contenu" (content sniffing) lorsqu'il est utilisé.

3.1.2. Encoding for Compression or Integrity (Encodage pour la compression ou l'intégrité)

3.1.2.1. Content Codings (Codages de contenu)

Les valeurs de codage de contenu (content coding values) indiquent une transformation d'encodage qui a été ou peut être appliquée à une représentation. Les codages de contenu sont principalement utilisés pour permettre à une représentation d'être compressée ou autrement utilement transformée sans perdre l'identité de son type de média sous-jacent et sans perte d'informations. Fréquemment, la représentation est stockée sous forme codée, transmise directement, et décodée uniquement par le destinataire.

content-coding   = token

Toutes les valeurs de codage de contenu sont insensibles à la casse et devraient être enregistrées dans le "registre de codage de contenu HTTP" (HTTP Content Coding Registry), tel que défini dans la Section 8.4. Elles sont utilisées dans les champs d'en-tête Accept-Encoding (Section 5.3.4) et Content-Encoding (Section 3.1.2.2).

Les valeurs de codage de contenu suivantes sont définies par cette spécification :

• compress (et x-compress) : format de données "compress" UNIX [Welch]. Historique ; non recommandé pour une utilisation dans de nouvelles applications.

• deflate : le format "zlib" [RFC1950] en combinaison avec le mécanisme de compression "deflate" [RFC1951].

• gzip (et x-gzip) : codage LZ77 avec un CRC 32 bits [RFC1952].

• identity : le codage "identity" (pas de transformation). Ce codage est utilisé uniquement dans le champ d'en-tête Accept-Encoding, et ne devrait pas (SHOULD NOT) être utilisé dans le champ d'en-tête Content-Encoding.

3.1.2.2. Content-Encoding (Encodage de contenu)

Le champ d'en-tête Content-Encoding indique quels codages de contenu ont été appliqués à la représentation, au-delà de ceux inhérents au type de média, et donc quels mécanismes de décodage doivent être appliqués afin d'obtenir les données dans le type de média référencé par le champ d'en-tête Content-Type. Content-Encoding est principalement utilisé pour permettre la compression des données d'une représentation sans perdre l'identité de son type de média sous-jacent.

Content-Encoding = 1#content-coding

Un exemple de son utilisation est :

Content-Encoding: gzip

Si un ou plusieurs encodages ont été appliqués à une représentation, l'expéditeur qui a appliqué les encodages doit générer (MUST) un champ d'en-tête Content-Encoding qui répertorie les codages de contenu dans l'ordre dans lequel ils ont été appliqués. Des informations supplémentaires sur les paramètres d'encodage peuvent être fournies par d'autres champs d'en-tête non définis par cette spécification.

Contrairement à Transfer-Encoding (Section 3.3 de [RFC7230]), les codages répertoriés dans Content-Encoding sont une caractéristique de la représentation ; la représentation est définie en termes de forme codée, et toutes les autres métadonnées sur la représentation concernent la forme codée, sauf indication contraire dans la définition des métadonnées. Typiquement, la représentation n'est décodée que juste avant le rendu ou une utilisation analogue.

Si le type de média inclut un encodage inhérent, tel qu'un format de données qui est toujours compressé, alors cet encodage ne serait pas répété dans Content-Encoding même s'il s'avère être le même algorithme que l'un des codages de contenu. Un tel codage de contenu ne serait répertorié que si, pour une raison bizarre, il est appliqué une seconde fois pour former la représentation. De même, un serveur d'origine pourrait choisir de publier les mêmes données sous plusieurs représentations qui ne diffèrent que par le fait que le codage est défini comme faisant partie de Content-Type ou Content-Encoding, car certains agents utilisateur se comporteront différemment dans leur traitement de chaque réponse (par exemple, ouvrir une boîte de dialogue "Enregistrer sous..." au lieu de la décompression et du rendu automatiques du contenu).

Un serveur d'origine peut (MAY) répondre avec un code d'état 415 (Unsupported Media Type) si une représentation dans le message de requête a un codage de contenu qui n'est pas acceptable.

3.1.3. Audience Language (Langue du public)

3.1.3.1. Language Tags (Balises de langue)

Une balise de langue (language tag), telle que définie dans [RFC5646], identifie une langue naturelle parlée, écrite ou autrement véhiculée par des êtres humains pour la communication d'informations à d'autres êtres humains. Les langages informatiques sont explicitement exclus.

HTTP utilise des balises de langue dans les champs d'en-tête Accept-Language et Content-Language. Accept-Language utilise la production language-range plus large définie dans la Section 5.3.5, tandis que Content-Language utilise la production language-tag définie ci-dessous.

language-tag = <Language-Tag, see [RFC5646], Section 2.1>

Une balise de langue est une séquence d'une ou plusieurs sous-balises insensibles à la casse, chacune séparée par un trait d'union ("-", %x2D). Dans la plupart des cas, une balise de langue se compose d'une sous-balise de langue primaire qui identifie une grande famille de langues apparentées (par exemple, "en" = anglais), qui est éventuellement suivie d'une série de sous-balises qui affinent ou rétrécissent la plage de cette langue (par exemple, "en-CA" = la variété d'anglais telle que communiquée au Canada). Les espaces ne sont pas autorisés dans une balise de langue. Les exemples de balises incluent :

en, en-US, en-cockney, i-cherokee, x-pig-latin

Voir [RFC5646] pour plus d'informations.

3.1.3.2. Content-Language (Langue du contenu)

Le champ d'en-tête Content-Language décrit la ou les langues naturelles du public visé pour la représentation. Notez que cela peut ne pas être équivalent à toutes les langues utilisées dans la représentation.

Content-Language = 1#language-tag

Les balises de langue sont définies dans la Section 3.1.3.1. Le but principal de Content-Language est de permettre à un utilisateur d'identifier et de différencier les représentations selon la langue préférée de l'utilisateur lui-même. Ainsi, si le contenu est destiné uniquement à un public danophone, le champ approprié est :

Content-Language: da

Si aucun Content-Language n'est spécifié, la valeur par défaut est que le contenu est destiné à tous les publics linguistiques. Cela peut signifier que l'expéditeur ne le considère pas comme spécifique à une langue naturelle, ou que l'expéditeur ne sait pas pour quelle langue il est destiné.

Plusieurs langues peuvent (MAY) être répertoriées pour le contenu destiné à plusieurs publics. Par exemple, une interprétation du "Traité de Waitangi" (Treaty of Waitangi), présentée simultanément dans les versions originales maori et anglaise, nécessiterait :

Content-Language: mi, en

Cependant, le simple fait que plusieurs langues soient présentes dans une représentation ne signifie pas qu'elle est destinée à plusieurs publics linguistiques. Un exemple serait un manuel de langue pour débutants, tel que "Une première leçon de latin" (A First Lesson in Latin), qui est clairement destiné à être utilisé par un public anglophone. Dans ce cas, le Content-Language ne devrait correctement inclure que "en".

Content-Language peut (MAY) être appliqué à n'importe quel type de média - il n'est pas limité aux documents textuels.

3.1.4. Identification (Identification)

3.1.4.1. Identifying a Representation (Identification d'une représentation)

Lorsqu'une représentation complète ou partielle est transférée dans une charge utile de message, il est souvent souhaitable pour l'expéditeur de fournir, ou pour le destinataire de déterminer, un identificateur pour une ressource correspondant à cette représentation.

Pour un message de requête :

• Si la requête a un champ d'en-tête Content-Location, alors l'expéditeur affirme que la charge utile est une représentation de la ressource identifiée par la valeur du champ Content-Location. Cependant, une telle affirmation ne peut être considérée comme fiable que si elle peut être vérifiée par d'autres moyens (non définis par cette spécification). Les informations peuvent néanmoins être utiles pour les liens d'historique de révision.

• Sinon, la charge utile n'est pas identifiée.

Pour un message de réponse, les règles suivantes sont appliquées dans l'ordre jusqu'à ce qu'une correspondance soit trouvée :

1. Si la méthode de requête est GET ou HEAD et que le code d'état de la réponse est 200 (OK), 204 (No Content), 206 (Partial Content) ou 304 (Not Modified), la charge utile est une représentation de la ressource identifiée par l'URI de requête effective (Section 5.5 de [RFC7230]).

2. Si la méthode de requête est GET ou HEAD et que le code d'état de la réponse est 203 (Non-Authoritative Information), la charge utile est une représentation potentiellement modifiée ou améliorée de la ressource cible telle que fournie par un intermédiaire.

3. Si la réponse a un champ d'en-tête Content-Location et que sa valeur de champ est une référence au même URI que l'URI de requête effective, la charge utile est une représentation de la ressource identifiée par l'URI de requête effective.

4. Si la réponse a un champ d'en-tête Content-Location et que sa valeur de champ est une référence à un URI différent de l'URI de requête effective, alors l'expéditeur affirme que la charge utile est une représentation de la ressource identifiée par la valeur du champ Content-Location. Cependant, une telle affirmation ne peut être considérée comme fiable que si elle peut être vérifiée par d'autres moyens (non définis par cette spécification).

5. Sinon, la charge utile n'est pas identifiée.

3.1.4.2. Content-Location (Emplacement du contenu)

Le champ d'en-tête Content-Location fait référence à un URI qui peut être utilisé comme identificateur pour une ressource spécifique correspondant à la représentation dans la charge utile de ce message. En d'autres termes, si l'on devait effectuer une requête GET sur cet URI au moment de la génération de ce message, alors une réponse 200 (OK) contiendrait la même représentation qui est enfermée comme charge utile dans ce message.

Content-Location = absolute-URI / partial-URI

La valeur Content-Location n'est pas un remplacement de l'URI de requête effective (Section 5.5 de [RFC7230]). C'est une métadonnée de représentation. Elle a la même syntaxe et la même sémantique que le champ d'en-tête du même nom défini pour les parties de corps MIME dans la Section 4 de [RFC2557]. Cependant, son apparition dans un message HTTP a des implications spéciales pour les destinataires HTTP.

Si Content-Location est inclus dans un message de réponse 2xx (Successful) et que sa valeur fait référence (après conversion en forme absolue) à un URI qui est le même que l'URI de requête effective, alors le destinataire peut (MAY) considérer la charge utile comme une représentation actuelle de cette ressource au moment indiqué par la date d'origine du message. Pour une requête GET (Section 4.3.1) ou HEAD (Section 4.3.2), c'est la même chose que la sémantique par défaut lorsqu'aucun Content-Location n'est fourni par le serveur. Pour une requête de changement d'état comme PUT (Section 4.3.4) ou POST (Section 4.3.3), cela implique que la réponse du serveur contient la nouvelle représentation de cette ressource, la distinguant ainsi des représentations qui pourraient seulement rapporter l'action (par exemple, "Ça a marché !"). Cela permet aux applications de création de mettre à jour leurs copies locales sans avoir besoin d'une requête GET ultérieure.

Si Content-Location est inclus dans un message de réponse 2xx (Successful) et que sa valeur de champ fait référence à un URI qui diffère de l'URI de requête effective, alors le serveur d'origine prétend que l'URI est un identificateur pour une ressource différente correspondant à la représentation enfermée. Une telle prétention ne peut être considérée comme fiable que si les deux identificateurs partagent le même propriétaire de ressource, ce qui ne peut pas être déterminé de manière programmatique via HTTP.

• Pour une réponse à une requête GET ou HEAD, c'est une indication que l'URI de requête effective fait référence à une ressource qui est soumise à la négociation de contenu et la valeur du champ Content-Location est un identificateur plus spécifique pour la représentation sélectionnée.

• Pour une réponse 201 (Created) à une requête POST, la valeur du champ Content-Location est une référence à une ressource qui correspond aux données soumises (c'est-à-dire une ressource distincte de celle identifiée par l'URI de requête effective).

• Sinon, un tel Content-Location indique que cette charge utile est une représentation d'une ressource autre que la cible du message de requête, et n'a pas d'autre signification pour HTTP.

Si Content-Location est inclus dans un message de réponse et que la représentation se compose de plusieurs parties, comme indiqué par un Content-Type de "multipart/*", alors chaque partie peut (MAY) avoir son propre Content-Location pour indiquer la ressource correspondant à cette partie. Sinon, le Content-Location s'applique uniquement à la charge utile dans son ensemble.

3.2. Representation Data (Données de représentation)

Les données de représentation associées à un message HTTP sont soit fournies comme corps de charge utile du message, soit référencées par la sémantique du message et l'URI de requête effective. Les données de représentation sont dans un format et un encodage définis par les champs d'en-tête de métadonnées de représentation.

Le type de données des données de représentation est déterminé via les champs d'en-tête Content-Type et Content-Encoding. Ceux-ci définissent un modèle d'encodage ordonné à deux couches :

representation-data := Content-Encoding( Content-Type( bits ) )

3.3. Payload Semantics (Sémantique de la charge utile)

Certains messages HTTP transfèrent une représentation complète ou partielle comme "charge utile" (payload) du message. Dans certains cas, une charge utile peut contenir uniquement les champs d'en-tête de la représentation associée (par exemple, les réponses à HEAD) ou seulement une partie des données de représentation (par exemple, le code d'état 206 (Partial Content)).

Le but d'une charge utile dans une requête est défini par la sémantique de la méthode. Par exemple, une représentation dans la charge utile d'une requête PUT (Section 4.3.4) représente l'état souhaité de la ressource cible si la requête est appliquée avec succès, tandis qu'une représentation dans la charge utile d'une requête POST (Section 4.3.3) représente des informations à traiter par la ressource cible.

Dans une réponse, le but de la charge utile est défini à la fois par la méthode de requête et le code d'état de la réponse. Par exemple, la charge utile d'une réponse 200 (OK) à GET (Section 4.3.1) représente l'état actuel de la ressource cible, tel qu'observé au moment de la date d'origine du message (Section 7.1.1.2), tandis que la charge utile du même code d'état dans une réponse à POST peut représenter soit le résultat du traitement, soit le nouvel état de la ressource cible après l'application du traitement.

Une charge utile est considérée comme "complète" (complete) dans les cas suivants :

• la section d'en-tête entière a été reçue et la longueur du corps de charge utile indiquée est zéro ;

• une charge utile segmentée (chunked payload) est complète lorsque la partie du corps segmenté est complète (comme indiqué par le segment de longueur zéro et le CRLF de terminaison) ;

• une longueur de charge utile inconnue est complète lorsque la connexion est fermée.

3.4. Content Negotiation (Négociation de contenu)

Lorsque les réponses véhiculent des informations de charge utile, qu'elles indiquent un succès ou une erreur, le serveur d'origine a souvent 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 qui peuvent être rendus visibles dans le protocole : "proactive" (proactive), où le serveur sélectionne la représentation en fonction des préférences déclarées de l'agent utilisateur ; "reactive" (reactive), où le serveur fournit une liste de représentations parmi lesquelles l'agent utilisateur peut choisir ; et "request content" (contenu de requête), où l'agent utilisateur sélectionne la représentation pour une charge utile de requête. D'autres modèles de négociation de contenu incluent "conditional content" (contenu conditionnel), où la représentation se compose de plusieurs parties qui sont rendues de manière sélective en fonction des paramètres de l'agent utilisateur, "active content" (contenu actif), où la représentation contient un script qui fait des requêtes supplémentaires (plus spécifiques) en fonction des caractéristiques de l'agent utilisateur, et "Transparent Content Negotiation" ([RFC2295]), où la sélection de contenu est effectuée par un intermédiaire. Ces modèles ne sont pas mutuellement exclusifs, et chacun a des compromis en termes d'applicabilité et de praticité.

Notez que, dans tous les cas, HTTP n'est pas au courant 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 à travers les dimensions variables de la négociation de contenu, 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. HTTP ne prête aucune attention à l'homme derrière le rideau.

3.4.1. Proactive Negotiation (Négociation proactive)

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 (proactive negotiation) (également appelée négociation pilotée par le serveur). La sélection est basée sur les représentations disponibles pour une réponse (les dimensions sur lesquelles elle peut varier, telles que la langue, le codage de contenu, etc.) comparées à diverses informations fournies dans la requête, y compris à la fois les champs de négociation explicites de la Section 5.3 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 (en espérant éviter le délai d'aller-retour d'une requête ultérieure si la "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 qui décrivent 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 à la fois des capacités de l'agent utilisateur et de l'utilisation prévue de la réponse (par exemple, l'utilisateur veut-il la visualiser à 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 fait que les préférences de négociation proactive soient honorées de manière cohérente, car le serveur d'origine peut ne pas implémenter de négociation proactive pour la ressource demandée ou peut 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 7.1.4) est souvent envoyé dans une réponse soumise à une négociation proactive pour indiquer quelles parties des informations de requête ont été utilisées dans l'algorithme de sélection.

3.4.2. Reactive Negotiation (Négociation réactive)

Avec la négociation réactive (reactive negotiation) (également appelée négociation pilotée par l'agent), la sélection de la meilleure représentation de réponse (quel que soit le code d'état) est effectuée par l'agent utilisateur après réception d'une réponse initiale du serveur d'origine qui contient une liste de ressources pour des représentations alternatives. Si l'agent utilisateur n'est pas satisfait de la représentation de réponse initiale, il peut effectuer une requête GET sur une ou plusieurs des ressources alternatives, sélectionnées en fonction des métadonnées incluses dans la liste, pour obtenir une forme différente de représentation pour cette réponse. La sélection des alternatives peut être effectuée automatiquement par l'agent utilisateur ou manuellement par l'utilisateur en sélectionnant dans un menu généré (éventuellement hypertexte).

Notez que ce qui précède fait référence aux représentations de la réponse, en général, et non aux représentations de la ressource. Les représentations alternatives ne sont pas nécessairement des représentations de la même ressource, bien qu'elles puissent l'être.

Un serveur peut choisir de ne pas envoyer de représentation initiale, autre que la liste des alternatives, et indiquer ainsi 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 des 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 de support pour la sélection automatique, bien qu'elle n'empêche pas un tel mécanisme d'être développé en tant qu'extension.

3.4.3. Request Content Negotiation (Négociation de contenu de requête)

Lorsque les préférences de négociation de contenu sont envoyées dans la réponse d'un serveur à un client, le client peut utiliser ces préférences pour déterminer quelle représentation est la meilleure pour les requêtes ultérieures à cette ressource. Cela s'appelle la négociation de contenu de requête (request content negotiation) (également appelée "négociation de contenu en tant que qualité de service").

Par exemple, un champ d'en-tête Accept dans une réponse 415 (Unsupported Media Type) pourrait indiquer quels types de médias sont acceptés dans une requête PUT à cette ressource, ou le champ Accept-Language d'une réponse pourrait indiquer les préférences linguistiques du service.

---