Résumé

  • must-understand n’est pas conçu pour voyager seul. RFC 9111 recommande de lui adjoindre no-store, afin qu’un cache qui ignore la nouveauté adopte quand même le comportement prudent.
  • Comprendre ne signifie pas reconnaître trois chiffres ni analyser le nom de la directive. Le cache doit reconnaître le statut de la réponse et mettre en œuvre toutes les règles de cache définies pour ce statut.
  • Écarter no-store ne rend pas automatiquement la réponse stockable ou réutilisable. Les règles de méthode, d’autorisation, de cache partagé, de fraîcheur et de réutilisation continuent de s’appliquer.

Une transition écrite pour deux générations

La scène tient dans une ligne d’en-tête : Cache-Control: must-understand, no-store.

Pour un cache ancien, la première directive est inconnue. La règle d’extension de HTTP lui impose de l’ignorer. La seconde, en revanche, lui est familière : il ne stocke donc pas la réponse. Pour un cache qui implémente must-understand, le chemin est différent. S’il connaît le code de statut et applique toutes les obligations de cache qui lui sont propres, RFC 9111 lui demande normalement d’ignorer le no-store d’accompagnement. Il peut alors examiner les autres conditions de stockage.

Ce mécanisme permet un déploiement asynchrone. L’origine n’a pas besoin d’attendre que tous les intermédiaires aient été remplacés. L’ancien logiciel reçoit une consigne conservatrice qu’il comprend déjà. Le nouveau peut choisir la branche élargie, mais seulement sur présentation d’une capacité précise.

La confusion commence lorsqu’un guide ne retient que le nom spectaculaire. must-understand ressemble à une injonction adressée à toute la chaîne. Or le destinataire qui ne connaît pas cette extension doit justement l’ignorer. Sans no-store, il ne reste aucun repli prudent fourni par cette paire. L’unité de déploiement n’est donc pas un mot : c’est l’association des deux directives et la preuve qui autorise leur lecture différenciée.

Connaître un statut est une propriété d’exécution

RFC 9111 définit le verbe comprendre avec une rigueur bienvenue. Un cache comprend un code de statut s’il le reconnaît et s’il met en œuvre tout le comportement relatif au cache que sa définition prescrit.

Un analyseur peut lire la valeur numérique. Une interface peut afficher son libellé. Un client HTTP peut appliquer la sémantique générique de la classe lorsque le code lui est inconnu. Ces capacités ne démontrent pas que le moteur de cache respecte la règle particulière du statut.

Les normes montrent pourquoi cette nuance est décisive. RFC 6585 interdit aux caches de stocker les réponses 428, 429, 431 et 511. RFC 7538 décrit au contraire 308 comme stockable par défaut, sauf indication contraire de la méthode ou des contrôles explicites. Ces exemples ne constituent pas un catalogue complet ; ils prouvent que les statuts n’emportent pas tous la même conséquence.

Un produit qui sait afficher « 429 Too Many Requests » mais conserve la réponse comme un objet ordinaire ne comprend pas 429 au sens utile ici. De même, un test qui valide seulement l’analyse de must-understand mesure la grammaire, pas la conformité. Une déclaration globale telle que « RFC 9111 pris en charge » masque encore la granularité : quel statut, quelle version de sa définition, quel module et quels essais ?

Il faut donc conserver cinq faits distincts : le statut observé ; sa reconnaissance ; la mise en œuvre de ses obligations de cache ; la prise en charge de must-understand ; enfin le résultat de toutes les autres conditions de stockage et de réutilisation. Une seule case « compris » efface précisément la preuve dont dépend l’exception.

Pourquoi l’interdiction accompagne l’ouverture

Le modèle d’extension de RFC 9111 repose sur une asymétrie. Les directives inconnues doivent être ignorées afin de ne pas casser les caches déjà déployés. Une extension comportementale associe donc la nouveauté à une directive ancienne : le destinataire ignorant suit l’ancienne règle, tandis que le destinataire informé comprend comment la nouveauté la modifie.

Dans cette construction, no-store n’est ni une redondance ni une contradiction. Il est le plancher de sécurité opérationnelle. L’ancien cache sait s’arrêter. Le nouveau sait dans quelle circonstance étroite il peut lever cet arrêt.

RFC 9111 emploie ici SHOULD : une réponse avec must-understand devrait aussi contenir no-store, et un cache qualifié devrait ignorer ce dernier. La recommandation est forte sans devenir une permission inconditionnelle. Une exception peut exister, mais elle doit être justifiée par le contexte technique ; supprimer le compagnon pour économiser quelques caractères n’explique pas comment réagiront les caches non informés.

La paire ne commande pas non plus aux implémentations hostiles. Une norme décrit le comportement conforme, elle ne contrôle pas à distance un cache compromis. La transition peut être sûre entre participants conformes tout en restant insuffisante comme mécanisme de confidentialité.

Lever un verrou n’ouvre pas toutes les portes

« Ignorer no-store » et « stocker » sont deux décisions différentes. La première ne fait que retirer une interdiction de la liste.

RFC 9111 maintient les autres conditions : la méthode doit permettre le stockage, le statut doit être final, les exigences propres à certains statuts doivent être comprises, les règles liées à Authorization peuvent intervenir, un cache partagé doit respecter private, et la réponse doit présenter une base explicite ou définie par le statut pour être mise en cache. D’autres extensions peuvent encore modifier l’issue.

La réutilisation vient ensuite. Une réponse stockée n’est pas nécessairement utilisable pour la prochaine requête. La clé doit correspondre ; la réponse doit être fraîche, validée ou autorisée à être servie périmée. must-understand ne crée ni fraîcheur, ni validation, ni séparation correcte entre utilisateurs.

Les journaux devraient refléter cette succession. « Exception acceptée » ne suffit pas. Ils doivent identifier le statut et sa référence, la preuve de mise en œuvre, les deux directives reçues, le résultat des autres conditions, l’acte de stockage, puis l’éventuelle réutilisation. Sinon une branche conditionnelle finit par ressembler à une autorisation permanente.

Les registres désignent les règles, pas les logiciels conformes

L’IANA répertorie séparément les directives de cache et les codes de statut HTTP. Ces registres fournissent des noms stables et renvoient aux textes qui les définissent. Ils sont indispensables pour éviter les collisions et retrouver la règle pertinente.

Ils ne certifient aucune installation. Le fait que must-understand figure dans un registre ne prouve pas qu’un binaire le traite. Le fait qu’un numéro de statut soit enregistré ne montre pas qu’un cache applique son comportement particulier. Même une suite de tests réussie pour un statut ne préjuge pas d’un futur statut livré par un module distinct.

La capacité doit voyager avec son propre dossier : version du moteur, module de statut, exigences vérifiées et résultat des tests. must-understand fournit un point de branchement interopérable. Il ne remplit pas ce dossier à la place de l’opérateur.

Le changement introduit dans RFC 9111 est mesuré. Son historique précise que les caches ne sont plus obligés de comprendre les nouveaux codes de réponse sauf lorsque must-understand est présent. L’origine peut donc signaler que la sémantique particulière du statut est indispensable. Elle ne peut pas déclarer à distance qu’un intermédiaire inconnu est compétent.

Une limite explicite : ce n’est pas de la confidentialité

RFC 9111 avertit que no-store n’est ni fiable ni suffisant pour garantir la vie privée. Un cache malveillant ou compromis peut l’ignorer ; le réseau peut permettre l’écoute. L’association avec must-understand ne transforme pas cette limite.

Elle ne décide pas non plus qui peut recevoir la réponse, si un cache partagé sépare correctement les utilisateurs, si le transport est chiffré ou si les données restent protégées sur disque. Présenter l’en-tête comme un sceau de classification risquerait de détourner l’attention des contrôles qui portent réellement ces garanties.

Cette étude n’a testé aucun fournisseur et ne mesure ni taux d’adoption, ni fuite, ni fréquence d’incident. Les parcours de cache décrits sont des conséquences raisonnées des textes normatifs.

Sources et périmètre de preuve

Les registres et errata sont observés à la date de recherche. Le corpus établit une sémantique de protocole et une lecture de gouvernance, pas une conformité universelle des produits.