Summary

  • Le RFC 2068 de janvier 1997 donnait au navigateur le champ Accept-Language pour classer les langues acceptables à l’aide de poids de préférence.
  • Lorsque le serveur choisit une édition grâce à ce champ, Vary: Accept-Language indique au cache qu’il doit comparer la préférence linguistique avant de réutiliser la réponse.

Dans le RFC 2068 de janvier 1997, l’exemple d’Accept-Language demande d’abord le danois, puis l’anglais britannique, puis d’autres formes d’anglais. Les petits nombres q donnent un ordre de préférence. Le navigateur transporte cette liste avec la demande de page. Le serveur peut ouvrir directement le bon volume au lieu d’obliger le lecteur à commencer par le rayon des langues.

Le problème change de forme quand la réponse passe dans un cache commun. Une visiteuse demande /news en danois ; un autre demande exactement /news en français. Deux URL identiques peuvent conduire à deux textes différents. Si le cache range uniquement par adresse, il connaît l’emplacement du livre mais ignore la raison du choix de l’édition. Il risque de tendre au second lecteur ce qu’il a pris pour la première.

Le serveur dispose d’une étiquette supplémentaire : Vary. Dans la spécification HTTP Semantics actuelle, Vary: accept-language annonce que le champ de langue a pu peser dans le choix de la réponse. Le RFC 9111 sur les caches fixe la règle correspondante : une réponse ainsi marquée ne peut pas être réutilisée sans revalidation si les champs indiqués ne correspondent pas à ceux de la requête d’origine. Le cache conserve le livre danois et le plan de table qui dit à qui le servir.

Le défaut classique est une étiquette absente sur l’édition par défaut. Le RFC 9111 explique qu’un cache peut alors continuer à choisir cette édition pour des demandes ultérieures, même lorsqu’une autre réponse aurait mieux convenu. Nul besoin d’un incident spectaculaire : une réponse rapide, rangée sans mention de la langue qui comptait, suffit à créer un mauvais accueil.

Le champ Content-Language décrit la langue du contenu effectivement envoyé. RFC 9110 le distingue d’Accept-Language, qui exprime les souhaits du navigateur, et de Vary, qui guide la réutilisation par les caches. Le visiteur, le serveur et l’intermédiaire ne parlent pas depuis le même pupitre. Chacun a son indice propre.

Il reste à demander si le navigateur parle vraiment pour la personne assise devant l’écran. Le guide d’internationalisation du W3C imagine notamment quelqu’un utilisant un navigateur emprunté : les préférences enregistrées appartiennent à un autre. Des commandes de langue visibles permettent au lecteur de corriger la première supposition. Le RFC de 1997 relevait déjà qu’une liste détaillée envoyée à chaque requête pouvait révéler des préférences privées ; le texte actuel maintient la main de l’utilisateur sur cette liste.

La petite merveille tient dans cette circulation réglée. Le navigateur propose, le serveur choisit, le cache note la raison du choix, puis le lecteur peut demander autre chose. Sans le plan de table, même un service très rapide finit par apporter le mauvais journal.