Résumé

  • Dans RFC 9211, chaque membre de la liste structurée Cache-Status correspond à un cache. L’ordre va du cache le plus proche de l’origine à celui qui se trouve le plus près de l’utilisateur : il s’agit d’une succession de constats, non d’un vote.
  • Les paramètres ne valent que dans le contexte du membre qui les émet. Un hit peut porter sur une réponse périmée, ttl peut être négatif, et stored ou collapsed ne se lit qu’avec fwd.
  • Une gouvernance crédible conserve l’ordre, distingue identité déclarée et identité vérifiée, et adapte la divulgation au destinataire. Elle n’invente ni exhaustivité du chemin ni autorité centrale.

Un itinéraire que le champ ne prétend pas certifier

Prenons un contenu servi à travers un cache de bordure, une passerelle d’entreprise puis un cache de navigateur. Si chacun choisit d’ajouter Cache-Status, la réponse contient trois membres. Le premier décrit le cache proche de l’origine ; le dernier, celui proche de l’utilisateur. Entre eux, aucune synthèse automatique n’est prévue.

Cette disposition résout une difficulté pratique. Un seul mot, « hit », ne permettrait pas de savoir qui a évité un transfert. Dans la liste, chaque décision reste attachée à son auteur. Le premier cache peut avoir transmis la requête pour validation, le deuxième avoir stocké la réponse et le troisième avoir répondu localement lors d’un autre échange. Ces événements ne se contredisent pas.

RFC 9211 recommande au cache qui ajoute un membre de préserver les membres existants. Cette continuité rend possible l’examen du parcours. Mais « préserver » ne signifie pas « garantir ». Un cache peut n’émettre le champ que lorsqu’une option de débogage est active, ou ne fournir qu’une partie des paramètres. L’absence d’un membre ne démontre donc pas l’absence d’un intermédiaire.

La règle vaut aussi dans l’autre sens : une liste présente n’est pas un relevé notarié. Les champs HTTP peuvent être modifiés en route. Le lecteur dispose d’assertions arrivées à un point d’observation, pas d’une cartographie certifiée de toute l’infrastructure.

Le nom inscrit n’est pas une pièce d’identité

Chaque membre commence par un identifiant, sous forme de String ou de Token selon la syntaxe des Structured Fields. Le cache peut y placer un nom de produit ou de service, un nom d’hôte, une adresse IP ou une chaîne générée. Ce choix permet de doser l’exposition de la topologie.

Il faut résister à une équivalence commode : identifiant ne veut pas dire authentification. La valeur est fournie par le cache qui écrit le membre. La confiance éventuelle vient d’ailleurs : maîtrise du segment réseau, terminaison protégée, journal interne, connaissance de la chaîne de déploiement ou mécanisme d’intégrité distinct.

RFC 9421 décrit les signatures de messages HTTP. Elles peuvent entrer dans une politique séparée, avec des composants couverts et des clés explicitement gérés. Elles ne rendent pas les membres Cache-Status ordinaires automatiquement signés. Même en présence d’une signature, il reste à déterminer quel acteur a signé quoi et quelles transformations étaient autorisées.

Un dossier d’audit devrait donc conserver quatre colonnes conceptuelles : l’identifiant déclaré, le lieu de collecte, la preuve de liaison à un émetteur attendu et le niveau de confiance analytique. Une simple case « fiable » fait perdre le raisonnement qui permettrait de réexaminer la décision.

hit répond à une question étroite

Lorsque hit vaut true, le cache n’a pas transmis la requête et a obtenu la réponse depuis son stockage. Rien dans ce terme ne garantit que la réponse était encore fraîche. Si les règles applicables permettent de servir une réponse périmée sans transfert, il s’agit toujours d’un hit au sens du champ.

À l’inverse, un objet déjà stocké ne suffit pas. Si le cache a dû transmettre la requête, notamment pour revalidation, l’opération n’est pas un hit. RFC 9211 rend hit et fwd exclusifs afin de distinguer ces branches.

Cette précision change la mesure. Une équipe chargée de réduire la charge de l’origine peut s’intéresser aux requêtes non transmises. Une équipe de conformité voudra savoir si une réponse personnalisée pouvait être réutilisée. Une équipe de performance cherchera la fraîcheur et les délais de validation. Aucun de ces objectifs ne devrait emprunter le même compteur sans conserver les autres éléments.

Le bon tableau de bord n’additionne donc pas tous les hit de tous les membres. Il montre quel cache a déclaré quoi, à quel moment, dans quel contexte de réponse, puis permet une agrégation adaptée à une question nommée.

fwd organise les raisons, sans dévoiler toute la machine

Le paramètre fwd indique la raison la plus précise connue pour laquelle le cache a transmis la requête. La norme prévoit notamment le contournement, la méthode, l’URI, l’absence d’objet, l’état périmé ou la validation. Ce vocabulaire crée un socle commun sans imposer la même architecture interne.

Les paramètres associés ont des conditions. fwd-status n’a de sens qu’en présence de fwd ; s’il manque, le statut remis au client sert de valeur implicite. stored indique si la réponse obtenue après transmission a été stockée. collapsed dit si la requête a rejoint avec succès une requête déjà en cours ou si elle en a provoqué une nouvelle. stored et collapsed ne doivent pas être projetés sur un membre hit.

Une base de données aplatie transforme facilement l’inapplicable en false. C’est une erreur de sens. Une valeur absente peut signifier « non applicable », « non divulgué » ou « non observé ». Le modèle utile garde le membre, son ensemble de paramètres et les préconditions de chacun. La représentation normalisée devrait rester reliée au champ brut ordonné.

Cette discipline est d’autant plus importante que les Structured Fields possèdent une grammaire précise. Une découpe artisanale sur les virgules confondrait la structure et les valeurs. RFC 9211 s’appuie sur RFC 8941 ; RFC 9651 lui a ensuite succédé pour les Structured Fields. Cette histoire ne justifie pas de réécrire rétroactivement le contrat de RFC 9211.

ttl n’est pas l’horloge du parcours

ttl donne la durée de fraîcheur restante calculée par un cache, près du moment où celui-ci ajoute le champ. Le résultat peut intégrer les règles d’âge HTTP, des heuristiques et une configuration locale. Une valeur négative peut correctement signaler un contenu périmé.

Deux membres peuvent donc afficher des ttl différents sans anomalie. Ils n’observent pas forcément le même objet stocké, ne suivent pas forcément la même politique et ne calculent pas forcément au même instant. Soustraire leurs valeurs pour estimer la latence du réseau serait une déduction sans base.

Les analyses solides restent locales : ce cache sert-il souvent sans transmission alors que son ttl est négatif ? Une modification de sa configuration a-t-elle changé la distribution des valeurs ? Demande-t-il une validation alors que sa propre durée reste positive ? Le champ peut guider l’enquête, mais il ne remplace ni les règles de cache ni les journaux concernés.

Il faut aussi dater la capture. Cache-Status décrit le traitement d’une réponse donnée. Une nouvelle requête peut emprunter une autre route ou rencontrer un autre état. Deux chaînes différentes peuvent être toutes deux exactes dans leur contexte.

key et detail : utiles, donc sensibles

key fournit une représentation propre à l’implémentation de la clé de cache. detail accueille une information locale. La norme prévient qu’une même valeur de detail peut avoir des significations différentes chez deux caches. Une sémantique destinée à l’interopérabilité mérite plutôt un paramètre enregistré ou un champ distinct.

Le registre IANA des paramètres Cache-Status, placé sous Expert Review, offre cette trajectoire. Les notions génériques peuvent être partagées ; les extensions liées à un fournisseur gardent un nom de portée comparable. Le registre coordonne les définitions. Il ne décide pas ce qu’un opérateur doit exposer à chaque utilisateur.

La section de sécurité de RFC 9211 explique pourquoi. Les informations peuvent aider à sonder les composants, à déduire une activité, à préparer une attaque temporelle ou à comprendre les ingrédients d’un empoisonnement de cache. Masquer superficiellement une clé ne suffit pas. Un nom d’hôte ou un détail de routage apparemment banal peut déjà enrichir une carte d’attaque.

Une politique à plusieurs niveaux est préférable : indications génériques sur les réponses publiques, paramètres plus détaillés pour un diagnostic authentifié, informations de clé réservées à des journaux protégés. La validité syntaxique n’est jamais, à elle seule, une autorisation de publier.

Mode de lecture recommandé

Conserver d’abord le champ exact, l’heure, la requête pertinente et le point d’observation. Le parser ensuite comme une liste structurée ordonnée. Créer une unité d’analyse par membre, sans déplacer un paramètre vers le membre voisin.

Appliquer ensuite les conditions sémantiques : opposition hit/fwd, paramètres dépendant de fwd, ttl local, detail local. Ajouter enfin une qualification de confiance qui ne modifie pas le contenu déclaré. Une assertion peut être parfaitement bien formée et rester non vérifiée.

Le résultat pourra dire : « Le membre se présentant comme la bordure régionale a déclaré un miss et un stockage ; le membre suivant a déclaré un hit ; le premier est relié à une infrastructure gérée, le second ne dispose pas d’une preuve d’identité indépendante. » Cette formulation refuse le confort trompeur d’un verdict global, mais elle permet de reproduire l’analyse.

Sources