Le mécanisme HTTP de négociation de contenu

Le serveur a souvent différentes manières de représenter les informations envoyées dans une réponse suite à une requête. Les données peuvent en effet être disponibles 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 la représentation, parmi celles disponibles, qui serait la meilleure à fournir.

Pour cette raison, HTTP fournit des mécanismes de négociation de contenu qui vont, comme le nom l’indique, permettre une négociation entre le client et le serveur pour obtenir la représentation la plus appropriée.

 

Quels sont les modèles de négociation de contenu HTTP disponibles ?

Les deux modèles de négociation de contenu les plus communs sont la négociation proactive et la négociation réactive.

Négociation proactive : le serveur sélectionne la représentation en fonction des préférences déclarées de l’agent utilisateur.

Négociation réactive : le serveur fournit une liste de représentations pour l’agent utilisateur à choisir.

Il existe également d’autres modèles de négociation de contenu comme :

  • Le contenu conditionnel : 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 : la représentation contient un script qui fait des demandes supplémentaires (plus spécifiques) en fonction des caractéristiques de l’agent utilisateur ;
  • La négociation transparente de contenu : la sélection de contenu est effectuée par un intermédiaire.

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 est entièrement déterminée par l’entité ou l’algorithme qui sélectionne ou génère ces réponses.

nbsp;

La négociation proactive en détail

La négociation de contenu est dite proactive lorsque les préférences de négociation de contenu sont envoyées par l’agent utilisateur au sein d’une requête pour encourager un algorithme situé au niveau du serveur à sélectionner la représentation préférée.

La négociation proactive est donc toujours une négociation pilotée par le serveur puisque c’est lui qui décide in-fine de la représentation à fournir au client (en tenant compte des préférences décrites par ce dernier).

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.) par rapport aux diverses informations fournies dans la requête.

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 dans l’espoir que celle-ci soit suffisante (et donc dans l’espoir d’éviter un nouvel aller-retour de requête-réponse).

Afin d’aider le serveur à deviner la meilleure représentation, un agent utilisateur peut envoyer des champs d’en-tête de demande qui décrivent ses préférences.

D’un autre côté, la négociation proactive présente des inconvénients inhérents à sa définition :

  • Il est impossible pour le serveur de déterminer avec précision ce qui pourrait être « le meilleur » pour un utilisateur donné ;
  • Demander à l’agent utilisateur de décrire ses capacités dans chaque demande peut être à la fois très inefficace (étant donné que seul un petit pourcentage des réponses ont plusieurs représentations) et un risque potentiel pour la confidentialité de l’utilisateur ;
  • La réutilisabilité des réponses pour la mise en cache partagée est limitée.

En plus de cela, un agent utilisateur ne peut pas compter sur le respect constant des préférences de négociation proactives, car le serveur d’origine peut ne pas implémenter la négociation proactive pour la ressource demandée ou peut décider que l’envoi d’une réponse non conforme aux préférences de l’agent utilisateur est préférable à l’envoi d’une réponse 406 (Not Acceptable).

Un champ d’en-tête Vary est souvent envoyé dans une réponse soumise à une négociation proactive pour indiquer quelles parties des informations de demande ont été utilisées dans l’algorithme de sélection.

 

Le champ d’en-tête Vary

Le champ d’en-tête Vary dans une réponse décrit quelles parties d’un message de demande, à part la méthode, le champ d’en-tête de l’hôte et la cible de la demande, peuvent influencer le processus du serveur d’origine pour sélectionner et représenter cette réponse.

Cela permet de déterminer comment les en-têtes de requêtes future sont associés pour décider si une réponse en cache peut être réutilisée plutôt que de solliciter à nouveau le serveur d’origine.

La valeur de Vary peut être soit *, soit une liste de noms de champs d’en-tête. La valeur * indique que tout dans la requête peut jouer un rôle dans la sélection de la représentation de la réponse. Une valeur composée d’une liste de noms séparés par des virgules indique que les champs d’en-tête de requête nommés peuvent jouer un rôle dans la sélection de la représentation.

Par exemple, une réponse contenant Vary : accept-encoding, accept-language indique que le serveur d’origine peut avoir utilisé les champs Accept-Encoding et Accept-Language de la requête (ou leur absence) comme facteurs déterminants lors du choix du contenu de cette réponse.

 

La négociation réactive en détail

La négociation de contenu est dite réactive lorsque la sélection de la meilleure représentation de réponse est effectuée par l’agent utilisateur après avoir reçu 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 par 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 de représentation différente pour cette réponse. La sélection des alternatives peut être effectuée automatiquement par l’agent utilisateur ou manuellement par l’utilisateur sélectionnant à partir d’un menu généré.

Notez qu’on parle ici généralement de représentations multiples de la réponse et non pas de la ressource demandée en soi.

Un serveur peut choisir de ne pas envoyer une représentation initiale mais seulement une liste d’alternatives pour indiquer ainsi que la négociation réactive par l’agent utilisateur est préférée.

Par exemple, les alternatives répertoriées dans les réponses avec le code de statut 300 (Multiple Choices) incluent des informations sur les représentations disponibles afin que l’utilisateur ou l’agent utilisateur puisse réagir en effectuant une sélection.

La négociation réactive est souhaitée lorsque le serveur d’origine est incapable de déterminer les capacités d’un agent utilisateur à partir de l’examen de la requête.

La négociation proactive souffre également d’inconvénients inhérents à sa définition comme le fait de transmettre une liste d’alternatives à l’agent utilisateur et de nécessiter une deuxième requête pour obtenir une représentation alternative qui augmentent la latence perçue.