Résumé

  • Le projet No-Vary-Search permet aux caches compatibles d’écarter certaines différences de requête pour reconnaître une réponse réutilisable. Il ne remplace ni la fraîcheur, ni les contrôles d’accès, ni la négociation de contenu, et ne certifie pas l’équivalence des décisions de l’application.
  • Chrome décrit une frontière précise : une page prérendue observe d’abord son URL de préparation, puis reçoit l’URL finale lorsque la navigation équivalente l’active. L’état dépendant des paramètres doit être établi ou révisé à ce moment. Une adresse corrigée ne prouve pas qu’un modèle ou une cible d’action a suivi.

Deux fiches produit partagent la même enveloppe HTML. Leur identifiant figure dans la partie requête de l’URL ; il sert ensuite au code du client pour obtenir les données propres à chaque fiche. Avant tout clic, le navigateur prépare une page. Celle-ci lit un premier identifiant et le conserve. Le lecteur choisit finalement l’autre produit. Le navigateur estime pouvoir réutiliser le document, l’active et remplace son adresse par celle du choix réel.

Le choix de l’application a-t-il changé avec l’adresse ?

L’égalité des documents initiaux ne répond pas à cette question. Elle peut être parfaitement justifiée, tandis qu’un modèle, une attribution de visite ou la cible d’une action ultérieure reste attaché à l’identifiant préparatoire. Une variable capturée ne se met pas à jour par le seul déplacement de l’adresse affichée. Ce scénario illustre un risque de conception ; il ne rapporte pas un défaut observé de Chrome ni un incident chez un utilisateur.

No-Vary-Search rend cette distinction concrète. Le mécanisme peut dire qu’une différence entre deux requêtes ne nécessite pas une autre réponse du serveur. Il ne peut pas décider que toutes les opérations préparées à partir de la première URL conviennent au choix finalement effectué. Confondre ces deux propositions revient à étendre une optimisation de cache jusqu’à une décision qu’elle n’avait pas vocation à prendre.

Le périmètre de l’équivalence reste celui de la réponse

À la date de cette recherche, draft-ietf-httpbis-no-vary-search-09 est la dernière version active du projet du groupe de travail HTTPBIS. Le texte d’août 2026 expire le 18 février 2027. Datatracker indique sa soumission pour publication et l’état « Approved-announcement to be sent::AD Followup », avec Proposed Standard comme statut RFC visé. La procédure d’approbation a donc avancé ; il serait inexact de présenter le document comme une simple suggestion individuelle sans approbation. Il n’est pas pour autant présenté ici comme un RFC déjà publié.

Le champ proposé est un dictionnaire de Structured Fields. La liste params désigne les paramètres dont on peut ignorer les différences. La liste except conserve au contraire les paramètres nommés comme significatifs et permet d’écarter les autres. Les deux entrées ne peuvent pas coexister. key-order traite l’importance de l’ordre des noms de paramètres. Des formes reconnues mais invalides conduisent à la configuration de variation par défaut, pas à une permission silencieuse de tout ignorer.

Ce contrat n’efface pas les paramètres de l’URL. Il définit une comparaison supplémentaire pour la réutilisation. L’origine fournit le champ ; un intermédiaire ne doit pas l’insérer, le supprimer ou le modifier, sauf s’il agit comme origine de la réponse. Le cache doit prendre en charge l’extension pour que cette comparaison produise un effet. La présence de l’en-tête ne prouve pas un déploiement universel dans les navigateurs, les CDN ou les mandataires.

Les autres exigences demeurent. La possibilité de mettre une réponse en cache et sa fraîcheur restent régies par HTTP ; la négociation de contenu et Vary continuent de compter. Une correspondance No-Vary-Search n’autorise ni le partage d’une réponse personnelle avec un autre utilisateur, ni sa conservation sans limite. Elle porte sur les différences de requête qui ne changent pas sémantiquement la réponse servie, à l’intérieur de ce cadre.

L’identifiant d’un produit peut être indifférent à une enveloppe commune, mais indispensable à une réponse dans laquelle le serveur a déjà rendu les données du produit. Un paramètre de campagne peut ne rien changer au document dans une application et orienter une autre réponse ailleurs. La catégorie supposée du paramètre ne constitue pas une preuve. L’origine doit examiner ce qu’elle sert réellement.

Précharger une réponse et prérendre une page ne créent pas le même risque

La documentation officielle de Chrome précise le cycle de vie. No-Vary-Search peut servir aux navigations spéculatives par préchargement et par prérendu. Dans le second cas, la page observe initialement l’URL utilisée pour sa préparation. Quand un clic vise une URL dont seules des différences couvertes varient, Chrome peut activer la page déjà préparée et remplacer son URL par l’adresse finale.

Le document recommande de n’exécuter le JavaScript dépendant des paramètres qu’après l’activation. Il avertit également qu’un contenu rendu côté client peut devoir être actualisé à ce moment. Son exemple dissocie un HTML produit initialement identique de données produit qui deviennent différentes après le travail du client. Cette description concerne le comportement documenté de Chrome ; elle ne vaut pas déclaration de compatibilité pour tous les navigateurs.

Il faut donc garder des populations distinctes dans les tests. Précharger prépare une réponse ; prérendre peut préparer une page qui exécute du code avant de devenir visible. Le risque d’état capturé avant activation n’est pas, par définition, une conséquence de tout préchargement. Une navigation ordinaire réussie ne teste pas davantage le passage d’une URL spéculative à une autre URL active.

L’indication expects_no_vary_search dans les règles de spéculation n’apporte pas une garantie supplémentaire sur l’application. Elle exprime l’attente d’un en-tête et peut faciliter la préparation. La réponse réelle reste soumise au contrat de l’origine, et cet indice ne prouve pas qu’un modèle ou un formulaire se rattachera correctement à la navigation finale.

Le passage de relais doit devenir explicite : considérer comme provisoire ce qui dépend du choix anticipé, lire le choix réel à l’activation, puis remettre en cohérence ses projections. Une fiche visuellement corrigée avec une cible d’action inchangée ne suffit pas. Un nouveau chargement de données avec une attribution de visite restée ancienne ne suffit pas non plus. L’application doit distinguer la préparation utile d’une décision désormais fondée sur la navigation active.

Une adresse finale ne vaut ni état final ni consentement

Le test révélateur prépare une requête admissible et en active une autre. Il ne vérifie pas seulement le titre ou la barre d’adresse. Il examine l’enregistrement sélectionné, les données visibles et la cible d’une action déclenchée par l’utilisateur. L’identifiant final traverse-t-il tous les éléments qui en dépendent ? Ou l’application a-t-elle seulement remplacé une étiquette sur un état plus ancien ?

Il peut rester légitime de travailler en avance. L’enveloppe commune et les ressources réellement indépendantes de la requête n’ont pas besoin d’attendre le clic. Ce qui doit attendre, ou être révisé, est le statut du choix anticipé. Préparer une possibilité n’équivaut pas à lui attribuer l’autorité du choix réel.

L’activation n’est elle-même pas une autorisation générale. Elle indique quelle navigation est devenue effective. Les droits d’accès, le consentement et l’autorisation d’une opération aux conséquences externes restent d’autres questions. Rattacher une action au bon identifiant est nécessaire, mais n’autorise pas tout ce que l’application pourrait faire avec cet identifiant. Arriver sur une page n’est pas commander une divulgation ou une instruction externe.

La version 09 formule aussi une limite forte du côté du serveur. L’origine ne doit pas déclarer un paramètre sans effet si cela contourne un traitement requis pour une réutilisation sûre. Le texte cite notamment l’autorisation, l’identification de l’utilisateur, la vérification de signature, le consentement, le routage, l’audit et la révocation. Une bonne routine d’activation ne peut pas sauver une réponse dont le partage était déjà injustifié.

Dans un cache partagé, ignorer par erreur le paramètre qui sélectionne un contenu sensible peut faire circuler la réponse d’un utilisateur vers un autre. La discipline d’activation et la sécurité de la réponse sont donc complémentaires. L’une protège le rattachement des décisions après la préparation ; l’autre protège ce qui peut être réutilisé en premier lieu. Ni un temps de chargement excellent ni un document identique ne démontrent que les deux protections sont présentes.

Les noms de paramètres ne dispensent pas de respecter la comparaison

Le projet repose sur l’analyse application/x-www-form-urlencoded et les conventions WHATWG. Il ne demande pas d’enlever arbitrairement des morceaux de texte. La configuration par défaut compare exactement la partie requête. Une configuration différente introduit l’analyse en paires, le filtrage des paramètres pertinents et, si prévu, un tri stable par nom avant comparaison.

Il faut tester les encodages et les valeurs répétées. Un signe plus et un encodage en pourcentage peuvent modifier ce que le parseur compare. Ignorer l’ordre des noms ne signifie pas réordonner librement les valeurs associées à un même nom. Aucune normalisation Unicode n’est appliquée. Le projet souligne également que le décodage avec perte de séquences UTF-8 invalides peut rapprocher des chaînes auparavant distinctes. Une frontière de sécurité ne devrait pas dépendre du maintien de cette distinction après comparaison.

Ce sont des limites de preuve, pas une invitation à mettre chaque exemple de parseur dans une politique de direction. Le contrat minimal doit exiger la bonne comparaison et des tests négatifs significatifs. Les équipes locales peuvent choisir les paramètres à conserver selon leur réponse, mais pas substituer une intuition de similarité à l’algorithme dont dépend le cache.

Le sens des paramètres peut changer avant que les anciennes réponses disparaissent

La frontière d’activation se double d’une frontière de version. Un paramètre ignoré dans l’enveloppe actuelle peut orienter le rendu ou un choix client après une évolution. Une politique except qui ne conserve que quelques noms écarte aussi des paramètres encore inconnus. Une politique params étroite laisse significatifs les noms non listés. Les deux démarches peuvent être justifiées, mais elles distribuent différemment le risque de changement futur.

Il convient donc de réexaminer l’équivalence quand le sens d’un paramètre, la réponse du serveur ou la lecture côté client évolue. Associer la décision à une version et à un responsable permet de savoir quelle hypothèse doit être retirée. Tester une ancienne réponse stockée face aux nouvelles navigations est plus instructif que tester exclusivement un nouvel en-tête sur un document neuf. Cette procédure est une recommandation de gouvernance de l’auteur, pas un nouveau champ imposé par IETF.

Modifier l’en-tête à l’origine ne réécrit pas rétrospectivement les objets déjà en cache. Le projet utilise la configuration de la réponse stockée et permet des stratégies tenant compte d’une politique conflictuelle plus récente. Il ne garantit pas son remplacement instantané partout. Il ne modifie pas non plus les exigences d’invalidation : invalider des URI conceptuellement équivalentes reste permis mais non obligatoire. Une écriture ne prouve donc pas que toutes les variantes considérées comme équivalentes sont devenues inutilisables.

Faire varier un paramètre pour forcer un téléchargement neuf peut échouer si l’ancienne politique l’ignore. Une migration doit s’appuyer sur une validation, une invalidation ou un espace de ressources distinct adapté au déploiement, et non sur la croyance générale qu’une nouvelle requête impose un nouveau travail. Le choix dépend du cache et du déploiement, et doit être vérifié sur les anciennes réponses encore éligibles.

Laisser la décision future à l’endroit où elle devient connaissable

Les notes de heng.lu sur la spécification initiale minimale, la décision future localisée et l’adoption volontaire donnent ici une discipline utile. Il s’agit de définir ce qui peut être partagé et le point où un choix ultérieur reste local, sans centraliser toutes les sélections produit ni interdire la spéculation efficace.

L’origine garde une promesse étroite sur la réponse. Le navigateur expose un passage de relais documenté. L’application rattache alors ses décisions aux paramètres de la navigation devenue réelle. « Même page » cesse d’être un raccourci qui confond trois responsabilités. Les équipes peuvent adopter le mécanisme avec une frontière vérifiable, plutôt qu’avec une confiance indifférenciée dans l’optimisation.

Même le bénéfice de confidentialité doit être décrit avec mesure. Le projet explique qu’un cache privé peut éviter certains traitements d’identifiants de suivi par l’origine. Un cache partagé reçoit toujours les requêtes qui les portent, et l’en-tête ne désactive pas le suivi côté client. Réutilisation ne signifie pas anonymat ; activation ne signifie pas consentement. Le gain durable est une promesse plus modeste : préparer tôt une réponse équivalente, puis décider lorsque le choix du lecteur est effectivement connu.

Sources

  1. Datatracker : état actuel du projet No-Vary-Search.
  2. Historique des versions.
  3. Version 09 archivée : comparaison, cache et sécurité.
  4. Version 09 en texte brut.
  5. Source structurée de la version 09.
  6. Texte maintenu par HTTP Working Group.
  7. Discussion dans le dépôt des extensions HTTP.
  8. Working Group HTTPBIS.
  9. RFC 9110 : sémantique HTTP.
  10. RFC 9111 : mise en cache HTTP.
  11. RFC 9651 : Structured Fields pour HTTP.
  12. RFC 6943 : comparaison d’identifiants et sécurité.
  13. Standard URL de WHATWG.
  14. Standard Infra de WHATWG.
  15. Chrome : prérendu et avertissements d’activation No-Vary-Search.
  16. heng.lu : spécification minimale et décision future localisée.
  17. heng.lu : The Policy Mirror.