Résumé

  • La RFC 2295 rendait visibles, dans une liste lisible par machine, plusieurs représentations associées à un URI HTTP ; une réponse de type liste ne contenait toutefois aucune donnée de variante.
  • Le choix, la récupération et l’affichage restaient séparés. Selon les conditions prévues, le serveur pouvait renvoyer une variante choisie ; le client pouvait aussi sélectionner puis récupérer l’une des variantes annoncées.

Une ressource, plusieurs réponses possibles

À la fin des années 1990, le Web devait déjà composer avec un décalage concret. Une ressource pouvait exister en HTML ou en PostScript, en anglais ou en français, avec des exigences différentes selon le logiciel qui la consultait. L’éditeur pouvait publier des URL distinctes ou négocier plusieurs versions derrière un même URI. Mais il ne suffisait pas de choisir : les intermédiaires, notamment les caches, devaient aussi distinguer les réponses correspondant à des requêtes différentes.

La RFC 2295, « Transparent Content Negotiation in HTTP », proposait un mécanisme expérimental pour rendre ces options visibles. Daté de mars 1998, le texte appelait variante chacune des versions et décrivait une liste liée à une ressource négociable. L’en-tête Alternates pouvait associer à chaque candidate son URI et des attributs tels que le type de média, la langue, une qualité de source ou des caractéristiques. « Transparent » signifiait que les variantes présentes sur le serveur d’origine devenaient visibles aux parties extérieures ; cela ne voulait pas dire que tous les navigateurs négociaient automatiquement ni que le choix devenait imperceptible.

Le mécanisme nommait quatre dimensions : type de média, jeu de caractères, langue et caractéristiques. Cette dernière ouvrait la négociation à des propriétés que les trois premières ne décrivaient pas, par exemple certaines extensions du HTML ou des capacités d’un format. Le codage de contenu — la compression, notamment — restait orthogonal ; ce n’était pas une cinquième dimension des variantes. Cette limite est utile : le document cherchait à décrire la représentation adaptée, et non chaque transformation possible de ses octets.

Trois traces, pas un seul événement

La réponse de type liste était un inventaire. La RFC la définit comme une réponse qui fournit la liste des variantes, mais aucune de leurs données. Un agent utilisateur prenant en charge la négociation pouvait comparer les candidates, puis en récupérer une en adressant une requête HTTP ordinaire à son URI. L’exemple de la RFC sépare clairement les opérations : le serveur envoie d’abord la liste ; le client demande ensuite paper.1 ; c’est la seconde réponse qui transporte le document. Une réponse 300 Multiple Choices pouvait aussi inclure une page permettant un choix manuel, y compris par un agent qui ne négociait pas. Même dans ce cas, la liste n’était pas la représentation choisie.

Le serveur n’était pas réduit au rôle de catalogue. Une choice response renvoyait la représentation de la meilleure variante et pouvait également fournir la liste. Il lui fallait cependant assez d’informations pour choisir au nom de l’agent, et la variante devait satisfaire la règle de proximité des URI définie par la RFC. La RFC 2296, mémo expérimental associé, précisait un algorithme de sélection à distance et rendait le choix conditionnel : si les éléments disponibles ne permettaient pas d’établir une meilleure variante positive et certaine, ou si la condition de proximité échouait, l’algorithme renvoyait une liste. Le client pouvait aussi appliquer son propre algorithme et, si la liste était présente, récupérer une autre variante.

Il est donc inexact de raconter cette histoire par « le client choisissait ». Il pouvait le faire ; le serveur aussi, dans les limites prévues. Le protocole séparait l’inventaire des candidates, l’autorité de décision, la réponse qui transportait les octets et l’affichage ultérieur. Du point de vue du serveur, l’en-tête Negotiate indiquait que l’agent déclarait prendre en charge la négociation transparente. Cette déclaration de capacité ne prouve pas qu’une requête donnée l’a utilisée.

Le cache faisait partie du protocole

La négociation peut faire produire à un même URI plusieurs représentations. Si un cache les confond, même un bon algorithme de choix donnera un mauvais résultat. La RFC 2295 s’appuyait donc sur Vary et sur les étiquettes d’entité, tout en ajoutant des validateurs de liste de variantes. Elle décrivait aussi comment extraire une réponse HTTP ordinaire d’une réponse de choix et comment la localisation de la variante se rattachait à la ressource négociable. La justesse du cache n’était pas un détail d’exploitation : elle faisait partie du contrat qui rendait plausible la réutilisation d’un URI.

Cette ambition avait un coût. Envoyer toutes ses préférences à chaque requête pouvait alourdir les en-têtes ; l’agent devait donc souvent examiner la liste localement. Or les préférences Accept peuvent révéler des caractéristiques du logiciel ou de l’environnement d’une personne. Le mémo abordait explicitement les fuites de confidentialité, l’usurpation de réponses venant des ressources variantes et les failles de sécurité révélées par la négociation. Ce sont des risques identifiés dans la conception, non la preuve qu’un incident déterminé s’est produit.

La RFC 2295 était expressément Experimental et précisait qu’elle ne définissait aucune norme Internet. Son mécanisme concernait GET et HEAD, pas toutes les transactions HTTP. La spécification permet de reconstituer une ambition : rendre les options inspectables en répartissant le choix entre clients, serveurs et caches. Les sources disponibles ici n’établissent ni recensement de la prise en charge par les navigateurs, ni taux de déploiement, ni résultat côté utilisateur. Une variante annoncée n’est pas forcément récupérée ; une réponse reçue ne prouve pas ce qu’une personne a vu.

Sources