Résumé

  • Cache-Status permet à chaque cache traversé de décrire sa décision dans une liste ordonnée : réponse locale, motif du transfert, validation, stockage, durée de fraîcheur ou regroupement de requêtes.
  • Chaque membre reste rédigé par le cache concerné et la plupart des paramètres sont facultatifs. Un hit peut être périmé, un TTL reste un calcul local et une liste bien formée ne garantit ni l’identité de ses auteurs ni l’exhaustivité du chemin.
  • Une exploitation responsable conserve le champ brut, le rapproche d’Age, Cache-Control, Via, des traces et de la télémétrie interne, puis sépare le droit de raconter l’incident du droit d’en tirer une décision.

Une panne, trois récits également plausibles

Une page corrigée au niveau de l’origine continue d’afficher une ancienne donnée chez certains clients. L’équipe applicative voit la bonne version. Le fournisseur de CDN ne détecte aucune alerte. La capture faite à la périphérie contient :

Cache-Status: Shield; hit; ttl=41, Edge; hit; ttl=12

Un premier récit accuse Edge : il a servi un objet local. Un deuxième accuse Shield : Edge n’a fait que réutiliser ce qu’il avait reçu auparavant. Un troisième innocente les deux, car un hit est attendu et les TTL sont positifs. Les trois récits extrapolent au-delà du champ.

Selon le RFC 9211, chaque hit affirme seulement que, pour cette requête, le cache n’a pas transféré la demande et a obtenu la réponse depuis son cache. Le champ ne dit pas si l’objet correspondait à la variante voulue par l’application, si une invalidation devait déjà l’avoir retiré, si son contenu était authentique ou si l’utilisateur possédait le droit de le recevoir. Même la fraîcheur n’est pas contenue dans le mot hit : une réponse périmée utilisée sans transfert peut être déclarée comme telle.

La valeur de Cache-Status commence donc là où le diagnostic sérieux devrait commencer : avec une affirmation étroite, située, que l’on peut confronter à d’autres réalités.

Une grammaire commune pour des systèmes hétérogènes

Les caches ont longtemps ajouté leurs propres en-têtes de diagnostic. Ils répondaient HIT, MISS ou par des codes propres à un produit, parfois accompagnés d’un nom de nœud ou d’une durée impossible à comparer. Cette abondance donnait l’impression d’observer le chemin tout en enfermant l’interprétation chez le fournisseur.

Cache-Status utilise les Structured Fields de HTTP pour imposer une forme commune. Sa valeur est une liste ; chaque membre représente un cache ayant traité la requête. Le premier se situe au plus près de l’origine et le dernier au plus près de l’utilisateur. Un cache de reverse proxy peut donc inscrire le premier élément, un shield conserver celui-ci et ajouter le sien, puis un cache de bordure compléter la séquence.

La syntaxe est modeste, mais son effet institutionnel est important. Un outil indépendant peut analyser les mêmes paramètres chez plusieurs implémentations. Un exploitant peut distinguer une absence d’URI d’un échec de sélection lié à Vary. Un responsable peut demander un vocabulaire d’extension enregistré au lieu d’accepter éternellement un code opaque.

Cette coordination ne crée pas une autorité centrale. Le cache choisit quand il émet le champ : toujours, sur configuration ou après activation d’un mode de débogage. Lorsqu’il ajoute son membre, il devrait préserver les valeurs présentes. Rien dans la liste ne rend cette conservation infalsifiable. La grammaire rend le récit lisible ; elle ne certifie ni la présence de tous les narrateurs ni leur sincérité.

Le membre est signé par un nom, pas par une identité

Chaque membre commence par un identifiant sous forme de chaîne ou de jeton. Il peut s’agir d’un produit, d’un service, d’un nom d’hôte, d’une adresse IP ou d’une valeur générée. Cette souplesse permet des déploiements publics et privés, mais elle interdit de prendre l’étiquette pour une identité vérifiée.

Edge-Paris peut être un alias stable, un groupe de machines ou une chaîne choisie pour masquer une topologie sensible. Cache-Status ne définit aucun certificat reliant ce nom à une société ou à une instance. Ce que l’observateur possède est la preuve qu’un message arrivé à un point donné contenait cette assertion.

Pour aller plus loin, il faut une cartographie opérationnelle : quel service peut écrire cet identifiant, sur quelles routes, sous quelle version de configuration et pour quel public. Il faut aussi une source distincte — trace, événement interne, journal d’origine ou capture authentifiée — capable de confirmer que l’état déclaré a réellement existé.

Cette distinction devient cruciale quand le prestataire contrôle à la fois la livraison et son explication. Ce n’est pas un motif de soupçon automatique ; c’est un motif de ne pas confondre témoignage direct et audit indépendant.

HIT ne signifie pas « bon »

Le paramètre hit est un booléen remarquablement facile à agréger. Son sens précis est moins confortable pour un tableau de bord.

Il indique une réponse fournie par le cache sans transfert de la requête. Une réponse issue initialement de l’origine mais transformée en 304 ou 206 peut encore constituer un hit si aucune demande n’est partie en amont pour cette opération. Une réponse périmée peut aussi être un hit lorsqu’une règle autorise son usage sans transfert, notamment dans certaines conditions de déconnexion.

Le droit de stocker et de réutiliser relève du RFC 9111, de Cache-Control, des validateurs, de Vary, des directives de requête et d’extensions comme stale-if-error. Cache-Status décrit une décision prise après l’application de ces éléments et de la configuration locale. Il ne peut pas rendre licite une réutilisation interdite.

Ainsi, quatre questions doivent rester distinctes : le protocole permet-il le stockage ou la réutilisation ; la configuration du cache applique-t-elle cette règle ; le champ rapporte-t-il fidèlement le choix ; et la représentation livrée convient-elle à l’utilisateur ? Un hit répond seulement à une partie de la troisième.

Les motifs de transfert sont plus précieux que MISS

Lorsque le cache a transféré la requête, fwd peut préciser sa raison. uri-miss signifie qu’aucune réponse ne correspondait à l’URI. vary-miss signifie qu’une URI correspondait mais qu’aucune variante ne satisfaisait les champs retenus par Vary. request indique qu’une réponse fraîche était sélectionnable, mais que la sémantique de la requête interdisait son emploi. stale signale qu’une réponse sélectionnée était périmée ; partial, qu’elle ne couvrait pas toute l’étendue demandée. method et bypass exposent encore d’autres décisions.

Ces différences commandent des remèdes opposés. Une hausse de uri-miss peut suivre un changement de chemins. Une hausse de vary-miss peut révéler une nouvelle dimension linguistique ou une incohérence de négociation. request peut venir de clients qui imposent une revalidation. bypass peut être parfaitement conforme à une politique, alors qu’un MISS générique laisserait croire à un cache vide.

Le standard demande d’employer la raison la plus précise connue lorsque l’implémentation le permet. Une organisation qui réduit ensuite toute cette richesse à HIT/MISS recrée volontairement l’ambiguïté que le standard avait supprimée.

TTL, validation, stockage et regroupement ne racontent pas la même chose

fwd-status révèle le statut renvoyé par le prochain saut. Un cache peut transférer une validation et recevoir 304, puis livrer 200 au client avec son objet réutilisé. Le paramètre aide à reconstituer cet échange, mais ne prouve pas que le validateur correspondait à la donnée métier correcte.

ttl exprime la durée de fraîcheur restante selon le calcul du cache au moment de l’émission. Cette durée peut intégrer une fraîcheur heuristique ou une règle locale et devenir négative. Elle n’est pas la date universelle d’expiration de l’objet. Elle ne remplace pas non plus Age, qui estime le temps écoulé depuis la génération ou la validation par l’origine en tenant compte du séjour dans les caches et du transport.

stored affirme que le cache a stocké une réponse transférée. Il ne promet ni sa résidence future, ni sa sélection par la requête suivante. collapsed montre qu’une requête a été regroupée avec d’autres transferts. Une réussite protège l’origine d’une rafale, mais concentre aussi l’effet d’une seule réponse sur plusieurs demandeurs.

key peut fournir une représentation de la clé de cache. C’est un outil exceptionnel pour diagnostiquer la normalisation des requêtes, Vary, la langue ou les frontières entre locataires. C’est également une information dangereuse : le RFC avertit qu’elle peut éclairer des attaques d’empoisonnement. detail, enfin, reste propre à l’implémentation ; la même valeur chez deux caches ne porte pas forcément le même sens.

L’absence de ces paramètres ne constitue pas un zéro. À l’exception des contraintes de sens entre certains paramètres, ils sont généralement facultatifs. Un tableau de bord qui convertit « absent » en « faux » invente une observation.

Une chaîne de divulgation, non un inventaire du chemin

Le client ne voit que les membres que les caches ont choisi d’émettre et que les intermédiaires ont préservés. Un navigateur peut ne rien ajouter. Un edge peut réserver le champ aux requêtes authentifiées. Un équipement de sécurité peut retirer les diagnostics. Une ancienne version peut oublier de conserver la valeur antérieure.

La liste ne découvre donc pas tous les caches : elle ordonne les témoignages parvenus jusqu’au point d’observation. Le champ Via apporte d’autres indications sur les relais et les versions de protocole. Proxy-Status décrit des erreurs et des traitements d’intermédiaires plus larges. Ces trois surfaces se complètent sans se garantir mutuellement.

La vérification doit se faire sur le trajet exécuté. Une requête synthétique doit traverser edge, shield, proxy inverse et passerelle. Des captures prises à plusieurs points doivent vérifier l’ordre, la conservation et les identifiants. Le test doit être répété pour un hit, un uri-miss, un vary-miss, une validation, un service périmé autorisé, un bypass et un regroupement. Un schéma d’architecture ne suffit pas à prouver le contenu du champ en production.

Rendre le témoignage plus fiable sans lui inventer une vérité

Un champ Cache-Status brut ne possède ni signature ni MAC définis par le RFC 9211. Les HTTP Message Signatures peuvent couvrir des champs sélectionnés, mais seulement dans un profil complet : composants obligatoires, clés, algorithmes, temps, autorité du signataire et règles d’échec.

Le profil doit explicitement couvrir Cache-Status. Il doit aussi tenir compte du moment où le signataire intervient : un cache ultérieur peut ajouter un membre après une signature antérieure. Même correctement vérifiée, la signature prouve le lien entre un signataire et les composants couverts ; elle n’observe pas la mémoire interne du cache pour certifier qu’un hit ou un stockage a réellement eu lieu.

Dans beaucoup de services, une signature sera disproportionnée. Une capture authentifiée, un accès de débogage contrôlé, des identifiants de trace et une télémétrie retenue hors du cache peuvent suffire. L’exigence est moins « tout signer » que « savoir quelle assurance existe, qui la produit et quelle affirmation elle autorise ».

La transparence peut devenir un oracle

Le RFC 9211 souligne que le champ peut aider un attaquant à sonder le cache et à déduire l’activité d’utilisateurs partageant celui-ci. La connaissance du stockage d’une réponse peut participer à une attaque temporelle. Une clé exposée peut révéler des transformations utiles à l’empoisonnement. Une simple obfuscation de clé ne supprime pas le risque sous-jacent.

Trois stratégies sont prévues : ne pas émettre, limiter l’émission aux clients autorisés, ou réserver les paramètres sensibles aux clients autorisés. Cache-Status devient alors un objet de contrôle d’accès.

Une forme publique minimale peut conserver l’identifiant de niveau, hit ou la raison de transfert. Un mode authentifié peut ajouter TTL, statut amont, stockage, regroupement et une représentation sûre de la clé. Une organisation plus sensible peut n’exposer aucun détail au public et exporter les événements vers une plateforme d’observation indépendante.

La bonne architecture évite les deux extrêmes : publier une cartographie exploitable au nom de la transparence, ou supprimer toute preuve externe jusqu’à rendre le client dépendant du seul récit du fournisseur.

Une méthode d’enquête fondée sur plusieurs témoins

Il faut d’abord conserver la réponse brute : valeur ordonnée complète, point et heure d’observation, méthode, URI cible et champs de requête pertinents. Les champs Date, Age, Cache-Control, Expires, ETag, Last-Modified, Vary, Via et Proxy-Status appartiennent au même dossier.

Ensuite, chaque membre doit être relié à un niveau attendu, une version et un état de configuration. Pour une clé, un condensat calculé avec secret ou une représentation autorisée est préférable à la copie d’une valeur sensible dans un ticket accessible à tous.

Puis vient la corroboration. Un hit doit correspondre à une recherche locale et à un objet identifiable. fwd=stale; fwd-status=304 doit correspondre à une requête conditionnelle. Un regroupement doit avoir un groupe et un nombre de demandeurs. Un stockage doit avoir un événement, sans que celui-ci promette l’absence d’éviction ultérieure.

Enfin, il faut revenir à l’application : la représentation livrée était-elle celle prévue pour cette identité, cette langue et ce locataire ? L’utilisateur reçoit-il désormais la bonne donnée ? Le passage de HIT à MISS après une purge n’est pas une preuve de rétablissement ; c’est seulement une nouvelle décision de cache.

Les tests qui donnent une portée réelle au standard

Une exploitation mature sait produire volontairement chaque état important, vérifier l’absence de transfert lors d’un hit, provoquer des échecs URI et Vary distincts, observer une validation 304, servir un objet périmé dans un cas autorisé, regrouper des requêtes simultanées et comparer le nombre d’attentes au trafic d’origine.

Elle teste aussi l’autorité de divulgation : aucune clé sensible sur une route publique ; détails limités au profil authentifié ; conservation de l’ordre après chaque mise à niveau d’intermédiaire ; valeur inconnue préservée sans interprétation inventée. Si une signature est utilisée, une modification d’un composant couvert doit provoquer l’échec et le profil doit prouver que Cache-Status figure réellement dans la base signée.

Le registre IANA Cache-Status coordonne les paramètres partagés et le registre des champs HTTP inscrit Cache-Status comme liste permanente. Ces registres stabilisent les noms. Seuls les tests du code en cours d’exécution peuvent établir la pratique d’un chemin donné.

Registre des éléments probants