Résumé

  • No-Vary-Search étend la comparaison des URI de cache selon une déclaration de l’origine : certains noms de paramètres ou leur ordre peuvent cesser de varier. Fraîcheur, validation, Vary et contrôles d’autorisation restent intacts.
  • L’adresse demandée n’est ni nettoyée ni réécrite. La déclaration doit exclure toute clé qui gouverne identité, consentement, signature, routage, audit ou révocation, car une fausse équivalence peut devenir une fuite entre utilisateurs.

La page d’un produit est demandée une première fois avec ?sku=18&utm_source=lettre, puis avec ?utm_source=partenaire&sku=18. L’application sait peut-être que utm_source ne change jamais le produit et que l’ordre des clés n’a aucun sens. Le cache, lui, voit deux URI. Lui demander d’apprendre seul leur égalité reviendrait à confondre corrélation et autorité.

Le projet draft-ietf-httpbis-no-vary-search-09, daté du 17 août 2026, fournit un langage pour transmettre cette connaissance limitée. Au 29 août, il s’agit encore d’un Internet-Draft actif de HTTPBIS, destiné au statut de Proposed Standard et approuvé dans l’attente de l’annonce, avec suivi de l’Area Director. Il n’a pas de numéro RFC. Le registre IANA des champs HTTP ne contient pas encore No-Vary-Search.

La prudence n’interdit pas l’expérimentation ; elle oblige à nommer exactement l’objet expérimenté. Le document actuel peut évoluer. Son état ne prouve ni le déploiement d’un cache, ni la correction d’une classification, ni le bénéfice annoncé.

Une exception bornée à la comparaison de l’URI

RFC 9111 encadre la réutilisation d’une réponse stockée. L’URI cible, la méthode, les champs désignés par Vary, la fraîcheur, la validation et les directives de cache doivent tous permettre le rapprochement. Deux requêtes dont la partie query diffère possèdent normalement deux URI cibles différentes.

Cette rigueur protège l’indépendance des applications. HTTP n’a aucun moyen universel de savoir si user=7, sig=abc ou color=blue est décoratif. Le nom d’une clé n’est pas un contrat et deux corps momentanément identiques ne démontrent pas que la distinction restera inutile.

No-Vary-Search ne modifie que cette étape de concordance. Il ne rend pas fraîche une réponse périmée, ne neutralise pas Vary, ne transforme pas une réponse privée en objet partagé et n’ouvre aucun droit d’accès. Après une équivalence de query, toutes les autres conditions de RFC 9111 doivent encore réussir.

La grammaire attribue la déclaration à l’origine

Le champ est un dictionnaire de Structured Fields. key-order est un booléen. params énumère les noms de paramètres ignorés. except décrit l’inverse : seuls les noms indiqués continuent à varier. params et except ne peuvent apparaître ensemble.

L’origine émet cette déclaration, car elle seule possède normalement la sémantique de l’application. Un intermédiaire ne doit ni insérer, ni supprimer, ni modifier le champ, sauf s’il agit comme origine de cette réponse. Une règle CDN déduite d’un échantillon de trafic n’est donc pas une optimisation équivalente : elle déplace le pouvoir vers la couche qui connaît le moins bien la finalité de la clé.

La défaillance est conservatrice. Une valeur absente, invalide ou contradictoire rétablit la comparaison exacte et sensible à l’ordre. Quelques hits sont perdus, mais aucune séparation supplémentaire n’est supprimée. Les clés de dictionnaire inconnues sont ignorées. Pour cette raison, une extension future ne pourra qu’agrandir l’ensemble d’URI équivalentes ; une future restriction devra employer un nouveau champ afin qu’un ancien destinataire ne réutilise pas trop largement.

Les octets visibles ne sont pas la comparaison réelle

Le mécanisme reste limité au même schéma, hôte, port et chemin. Il ne relie ni deux origines ni deux chemins. À l’intérieur de cette enceinte, une configuration non triviale analyse la query selon le modèle WHATWG application/x-www-form-urlencoded. Elle retire les paires ignorées ou conserve celles de except, peut trier les noms, puis compare noms et valeurs en préservant les doublons.

Le décodage des pourcentages, la conversion du signe plus en espace et le traitement des segments vides peuvent rapprocher des chaînes visiblement différentes. Un encodage UTF-8 invalide peut devenir le caractère de remplacement U+FFFD et faire converger deux suites d’octets distinctes. À l’inverse, aucune normalisation Unicode n’est appliquée : deux graphies NFC et NFD restent séparées.

La différence est opérationnelle lorsqu’une signature porte sur les octets originaux, lorsqu’un routeur interprète l’ordre des doublons ou lorsqu’une valeur vide active un comportement. Le projet déconseille le champ pour une query qui ne suit pas le modèle form-urlencoded. RFC 6943 décrit plus largement ces pièges d’identificateurs : lorsque deux couches n’appliquent pas la même comparaison, une égalité apparente peut relier des sujets différents.

Le cache choisit encore de réutiliser

Un cache compatible peut employer la comparaison étendue ; il n’y est pas obligé. Il peut chercher d’abord la clé exacte, construire un indice simplifié ou renoncer au hit. La déclaration de l’origine n’est pas un ordre : elle rend une option disponible à la couche qui assumera le résultat de la réutilisation.

La politique peut dériver. Si plusieurs réponses du même hôte et chemin portent des configurations non vides incompatibles, le projet permet de préférer celle associée à un champ Date plus récent. C’est un indice de convergence, non une vérité. Une mauvaise configuration peut être la plus récente et tous les nœuds ne la verront pas au même instant.

L’invalidation de RFC 9111 n’est pas étendue automatiquement. Après une méthode qui modifie l’état, un cache peut invalider les URI déclarées équivalentes, mais n’y est pas tenu. Deux représentations rapprochées à la lecture peuvent donc survivre différemment après écriture. De même, un suffixe query utilisé pour casser le cache devient inopérant si sa clé a été classée sans variation. Un nom de fichier adressé par son contenu reste une décision distincte et plus explicite.

Une équivalence de cache n’est pas un effacement

Le navigateur montre toujours l’URL complète. Le CDN reçoit les identifiants, les mandataires peuvent les journaliser, l’historique les conserve et les outils d’analyse peuvent les traiter. Le champ ne retire rien du message. Un cache privé peut éviter un passage ultérieur à l’origine ; un cache partagé continue de voir la requête.

La frontière de sécurité doit donc être absolue. Une clé qui influence l’identité, l’autorisation, la signature, le consentement, le routage, l’audit, la facturation, la révocation ou tout traitement nécessaire à une réutilisation sûre ne doit jamais être ignorée. L’image peut être identique alors que l’autorisation ponctuelle ne l’est pas. Le corps peut rester stable alors que l’attribution contractuelle exige un événement.

Dans un cache partagé, l’erreur extrême sert à Alice la réponse obtenue pour Bob. Les directives privées et le cloisonnement des caches demeurent nécessaires, mais ils ne justifient pas une déclaration fausse. L’origine porte la responsabilité de la classification ; le cache porte celle de la séparation au moment du hit.

La preuve commence là où l’origine disparaît

Le dossier de preuve doit réunir l’URL visible, l’URL de la réponse stockée, le champ brut, le dictionnaire analysé, les paires après transformation, l’entrée choisie, les vérifications ordinaires de RFC 9111, le contexte d’utilisateur et de partition, le bypass de l’origine et l’empreinte du corps livré. Un taux de hits seul ne distingue pas une bonne abstraction d’une fuite efficace.

La spécification commune minimale de Lu Heng éclaire le partage du pouvoir : le noyau commun est un dictionnaire et une comparaison ; la décision future sur le sens des clés reste locale à l’application ; l’adoption reste volontaire pour le cache. La primauté du code en fonctionnement demande ensuite d’observer l’entrée réellement choisie, pas seulement un champ configuré.

Enfin, la distinction entre souveraineté technique et pratique des données empêche une illusion commode. L’origine contrôle formellement le champ, mais le navigateur, le CDN et le cache conservent chacun une partie de la transaction. L’origine peut même ne jamais voir la seconde requête. La gouvernance doit suivre ces conséquences distribuées.

L’asymétrie correcte est simple : l’incertitude doit produire davantage de misses, jamais moins de séparation.