Résumé

  • HTTP Vary désigne les champs de requête qui ont pu influer sur le choix de représentation de l’origine ; avant de réutiliser la réponse sans validation, un cache doit comparer ces champs.
  • Le champ n’atteste ni la configuration réellement déployée, ni tous les critères applicatifs, ni la séparation des locataires ou des autorisations, ni l’empreinte de la réponse effectivement servie.

Imaginons une plateforme qui distribue une configuration propre à chaque locataire sous un URI commun. Le locataire A demande la ressource ; l’origine renvoie sa marque et ajoute Vary: Accept-Encoding. Un tableau de contrôle voit un champ Vary valide et déclare l’isolation conforme. Plus tard, le locataire B utilise le même codage de contenu et reçoit du cache périphérique les octets destinés à A.

Vary n’est pas en faute. Il décrit la dimension que l’origine a déclaré avoir utilisée pour cette réponse. L’erreur consiste à transformer cette déclaration limitée en preuve d’une frontière plus large qu’elle n’a jamais certifiée.

Ce que Vary affirme réellement

La RFC 9110 définit Vary comme le champ de réponse qui indique quelles parties de la requête, outre la méthode et l’URI cible, ont pu influencer le choix du contenu par le serveur d’origine. Lorsqu’il contient des noms de champs, ceux-ci deviennent les champs de sélection. C’est donc une déclaration de l’origine sur les entrées possibles d’un choix, pour une réponse donnée.

Le champ remplit deux fonctions. Il interdit aux caches de réutiliser la réponse si les champs désignés ne correspondent pas, sauf validation par l’origine. Il signale aussi à l’agent utilisateur qu’une négociation de contenu a eu lieu et que d’autres valeurs pourraient produire une autre représentation. Aucune de ces fonctions ne constitue une observation émise par le cache qui stockera ou servira ensuite la réponse.

Le caractère générique précise encore la limite. Vary: * signifie que des aspects extérieurs aux champs nommés, y compris éventuellement l’adresse réseau du client, ont pu peser sur le choix. Le destinataire ne peut alors établir l’adéquation d’une requête ultérieure à partir des seuls champs et doit la transmettre à l’origine. Un proxy ne doit pas générer ce caractère générique. Il exprime une incertitude, pas une commande universelle d’isolation.

La clé réelle du cache est un autre fait

La RFC 9111 appelle « clé de cache » l’information qu’un cache utilise pour choisir une réponse enregistrée. Elle comprend au minimum la méthode et l’URI cible. Le cache peut y ajouter les champs désignés par Vary, ainsi que d’autres éléments.

Si une réponse enregistrée contient Vary, le cache ne doit pas la réutiliser sans validation tant que tous les champs nommés ne correspondent pas à ceux de la requête qui a créé l’entrée. Certaines normalisations sont permises uniquement lorsqu’elles conservent la sémantique du champ. L’absence d’un champ désigné ne correspond qu’à son absence dans la requête suivante. Une réponse enregistrée contenant Vary: * ne correspond jamais.

Ces règles sont fortes, mais elles ne répondent pas à quatre questions d’exploitation. Le cache déployé a-t-il interprété et appliqué le champ ? Un intermédiaire l’a-t-il supprimé ou réécrit ? L’application a-t-elle choisi la représentation selon une donnée non déclarée, par exemple un locataire résolu après authentification ? L’objet livré correspond-il à la variante que le cache croyait avoir sélectionnée ? Vary apporte un élément de preuve ; il ne fournit pas ces réponses.

L’isolation dépend parfois de dimensions invisibles

Une application peut choisir une représentation d’après un compte authentifié, une correspondance de locataire, un groupe fonctionnel, une version de politique, une règle de juridiction ou une configuration de périphérie. Certains éléments sont présents dans la requête ; d’autres proviennent de l’état du serveur. La RFC 9110 permet Vary: * lorsque des facteurs extérieurs au message interviennent, mais cette valeur empêche la réutilisation ordinaire au lieu de décrire une partition privée réutilisable.

La simple présence de Vary, ou d’une liste limitée à la langue et au codage, ne prouve donc pas l’isolation. Un champ parfaitement valide peut être incomplet par rapport à la logique applicative. À l’inverse, un cache peut ajouter une partition de confidentialité non visible dans Vary. La réponse seule ne révèle aucun de ces deux cas.

Cette question ne se confond pas avec la fraîcheur. Une variante peut être fraîche et néanmoins incorrecte parce qu’un critère manque dans la clé. Elle peut être périmée tout en restant dans la bonne partition. Une revalidation peut confirmer l’usage d’une représentation sans prouver que la requête a rejoint le bon locataire. Fraîcheur, validation, autorisation et sélection de variante sont des contrôles liés, mais distincts.

Une preuve exploitable

Pour affirmer qu’un déploiement isole correctement ses représentations, il faut joindre le signal de protocole à l’action du cache. Le dossier doit conserver l’instance ou la cohorte de cache et sa version de configuration ; la méthode et l’URI ; la valeur Vary reçue ; les valeurs normalisées et l’état d’absence de chaque champ nommé ; tous les critères applicatifs ; le contexte de locataire et d’autorisation ; la décision de succès, d’échec ou de revalidation ; l’identité de l’objet stocké ; et l’empreinte des octets livrés.

Ce reçu de sélection de variante est une synthèse éditoriale de preuves, pas un élément de protocole défini par l’IETF. Il empêche qu’un signal normatif étroit soit présenté comme une assurance opérationnelle générale. Il doit aussi préciser le point d’observation : origine, cache intermédiaire et nœud périphérique peuvent voir des champs différents et appliquer des configurations différentes.

Vary est utile lorsque sa portée est respectée. Il rend la négociation déclarée visible et impose des règles de comparaison concrètes aux caches conformes. L’erreur commence quand la déclaration devient une preuve d’implémentation, d’isolation ou de résultat. Le champ indique des dimensions prévues ; seules la configuration observée et la livraison permettent de démontrer que la bonne représentation est restée du bon côté de la frontière.

Sources