12. Content Negotiation (Négociation de Contenu)
La plupart des réponses HTTP contiennent une entité qui comprend des informations destinées à l'interprétation par un utilisateur humain. Naturellement, il est souhaitable de fournir à l'utilisateur la "meilleure entité disponible" correspondant à la requête. Malheureusement, tous les utilisateurs n'ont pas les mêmes préférences quant à ce qui est "meilleur", et tous les agents utilisateurs ne sont pas également capables de rendre tous les types d'entités. Pour cette raison, HTTP fournit plusieurs mécanismes de "négociation de contenu" (content negotiation) - le processus de sélection de la meilleure représentation pour une réponse donnée lorsque plusieurs représentations sont disponibles.
Note : Cela n'est pas appelé "négociation de format" (format negotiation), car les représentations alternatives peuvent être du même type de média, mais utiliser des fonctionnalités différentes de ce type, utiliser des langues différentes, etc.
Toute réponse contenant un corps d'entité peut (MAY) faire l'objet d'une négociation, y compris les réponses d'erreur.
Il peut y avoir deux types de négociation de contenu dans HTTP : la négociation pilotée par le serveur (server-driven negotiation) et la négociation pilotée par l'agent (agent-driven negotiation). Ces deux types de négociation sont orthogonaux et peuvent donc être utilisés séparément ou en combinaison. Une approche combinée, appelée négociation transparente (transparent negotiation), se produit lorsqu'un cache utilise les informations de négociation pilotée par l'agent fournies par le serveur d'origine pour fournir une négociation pilotée par le serveur pour les requêtes ultérieures.
12.1 Server-driven Negotiation (Négociation Pilotée par le Serveur)
Si le choix de la meilleure représentation pour une réponse est effectué par un algorithme situé sur le serveur, on parle de négociation pilotée par le serveur. La sélection est basée sur les représentations disponibles de la réponse (les dimensions dans lesquelles elle peut varier ; par exemple, la langue, l'encodage du contenu, etc.) et le contenu de champs d'en-tête particuliers dans le message de requête ou d'autres informations relatives à la requête (telles que l'adresse réseau du client).
La négociation pilotée par le serveur est avantageuse lorsque l'algorithme de sélection parmi les représentations disponibles est difficile à décrire à l'agent utilisateur, ou lorsque le serveur souhaite envoyer sa "meilleure estimation" au client avec la première réponse (dans l'espoir d'éviter le délai d'aller-retour des requêtes ultérieures si la "meilleure estimation" est suffisamment bonne pour l'utilisateur). Pour améliorer la conjecture du serveur, l'agent utilisateur peut (MAY) inclure des champs d'en-tête de requête décrivant ses préférences pour de telles réponses (Accept, Accept-Language, Accept-Encoding, etc.).
La négociation pilotée par le serveur présente des inconvénients :
-
Il est impossible pour le serveur de déterminer avec précision ce qui pourrait être "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 requête particulière.
-
Demander à l'agent utilisateur de décrire ses capacités dans chaque requête est encombrant (consommant de la bande passante disponible) et peut entraîner des risques importants pour la vie privée (empreinte digitale de l'utilisateur).
-
Cela complique l'implémentation du serveur d'origine et rend l'algorithme difficile à vérifier.
-
Cela peut limiter les représentations publiquement disponibles lorsque l'algorithme du serveur fait des hypothèses sur les capacités des agents utilisateurs.
HTTP/1.1 inclut les champs d'en-tête de requête suivants pour activer la négociation pilotée par le serveur : Accept (section 14.1), Accept-Charset (section 14.2), Accept-Encoding (section 14.3), Accept-Language (section 14.4), et User-Agent (section 14.43). Cependant, un serveur d'origine n'est pas limité à ces dimensions et peut (MAY) varier la réponse en fonction de n'importe quel aspect de la requête, y compris les champs d'en-tête de requête non répertoriés ou les champs d'en-tête d'extension non présents dans la requête.
Le champ d'en-tête Vary peut être utilisé pour exprimer les paramètres utilisés lors de la sélection d'une représentation, ce qui peut être utile aux agents utilisateurs pour comprendre l'applicabilité du cache (voir section 13.6) et aux serveurs générant le champ d'en-tête Vary (voir section 14.44).
12.2 Agent-driven Negotiation (Négociation Pilotée par l'Agent)
Avec la négociation pilotée par l'agent, la sélection de la meilleure représentation pour une réponse est effectuée par l'agent utilisateur après avoir reçu une réponse initiale. La sélection est basée sur une liste des représentations disponibles (incluant leurs URI et leurs caractéristiques distinctives) et les préférences de l'utilisateur ou de l'agent utilisateur.
La négociation pilotée par l'agent est avantageuse lorsque la réponse varie selon des dimensions dans lesquelles le serveur d'origine ne peut pas déterminer avec précision ce qui est le meilleur pour l'agent utilisateur en examinant la requête, ou lorsqu'un cache public est utilisé pour réduire la charge du serveur et l'utilisation du réseau en configurant les agents utilisateurs.
La négociation pilotée par l'agent présente l'inconvénient suivant : une deuxième requête est nécessaire pour obtenir la meilleure représentation alternative. Cette deuxième requête n'ajoutera une latence perceptible que si le cache est capable de fournir la réponse correcte (déjà mise en cache) ou si la liste des ressources est petite. De plus, cette spécification ne fournit pas de norme pour la liste, ni pour que l'agent utilisateur sélectionne automatiquement le meilleur choix, cette spécification ne définit aucune norme pour une telle sélection automatique.
HTTP/1.1 définit les codes d'état 300 (Multiple Choices) et 406 (Not Acceptable) que les serveurs doivent utiliser lors de l'exécution d'une négociation pilotée par l'agent.
12.3 Transparent Negotiation (Négociation Transparente)
La négociation transparente est une combinaison de négociation pilotée par l'agent et pilotée par le serveur. Elle est utilisée lorsqu'un cache fournit une négociation pilotée par le serveur à un agent utilisateur en utilisant les informations de négociation de contenu fournies par le serveur d'origine.
L'avantage de la négociation transparente est qu'elle élimine un aller-retour de requête lorsque le serveur d'origine n'est pas disponible.
L'inconvénient de la négociation transparente est qu'elle peut conduire à la sélection d'une représentation incorrecte si les informations de négociation de contenu sont incomplètes ou inexactes.
HTTP/1.1 ne définit aucun en-tête pour la négociation transparente.