Résumé

  • Un membre Cache-Status décrit le traitement effectué par le cache qui l’ajoute; les paramètres hit et fwd ont une signification locale définie.
  • L’émission dépend du cache, les paramètres sont facultatifs et la divulgation peut être restreinte: une liste courte ne prouve donc pas l’absence d’autres caches ou décisions.

Imaginons une revue d’incident explicitement hypothétique. Une réponse contient Cache-Status: edge; hit. Le tableau de bord dessine une seule case verte, qualifie le trajet de «livraison par un cache unique» et affirme qu’aucun système amont n’est intervenu. Le membre peut être exact: le cache périphérique a bien répondu à cette requête sans la transférer. Mais un cache plus proche de l’origine a pu fournir la réponse stockée lors d’un échange antérieur, sans publier son propre membre. Le champ dit ce que le cache périphérique a fait maintenant; il ne reconstitue pas toute l’histoire de l’objet stocké.

La RFC 9211 confie à Cache-Status une fonction précise, mais bornée. Chaque membre de la liste représente un cache qui a traité la requête et choisi de se déclarer. Lorsque plusieurs membres subsistent, ils sont ordonnés du cache le plus proche de l’origine vers celui le plus proche de l’utilisateur. Un cache qui ajoute sa valeur devrait préserver celles déjà présentes. Ces règles rendent le champ précieux pour déboguer une chaîne visible.

La liste n’est toutefois pas garantie exhaustive. La norme indique que les caches décident quand l’ajout du champ est approprié. Un déploiement peut l’envoyer partout; un autre uniquement après configuration ou activation d’un mode de diagnostic par la requête. La politique de sécurité peut aussi justifier l’omission ou la divulgation sélective, car l’état du cache, l’activité des utilisateurs et la construction des clés peuvent faciliter des attaques. L’absence d’un membre signifie donc «non déclaré ici», pas nécessairement «aucun cache ici».

Les paramètres ont la même portée locale. hit signifie que le cache à l’origine du membre n’a pas transféré cette requête et a obtenu la réponse depuis son cache. fwd signifie qu’il l’a envoyée vers l’origine, avec éventuellement une raison comme uri-miss, vary-miss, stale ou request. Ces faits sont utiles et ne doivent pas être réduits à de vagues indicateurs de couleur.

Mais une vérité locale n’est pas une topologie complète. fwd-status décrit le statut renvoyé par le prochain saut; celui-ci peut être un autre intermédiaire et non l’origine. L’identifiant du cache peut être un nom de produit, un hôte, une adresse ou une chaîne générée. Les détails facultatifs dépendent du déploiement. Sans configuration ni point d’observation, deux libellés identiques ne garantissent pas le même rôle, et deux libellés différents ne prouvent pas deux infrastructures indépendantes.

La dimension temporelle compte aussi. Cache-Status décrit la réponse et la requête correspondantes. Un hit ne raconte pas quand ni par quel chemin la réponse stockée a été acquise. Il ne prouve pas que l’origine n’a jamais été contactée dans l’histoire de cet objet. Une seule réponse n’explique pas non plus le sort d’une requête voisine portant d’autres directives, identifiants, valeurs Vary ou conditions de fraîcheur. La RFC 9111 traite ces décisions comme propres à chaque requête.

Cette limite protège l’attribution des incidents. Un fwd=stale; fwd-status=304 visible étaye ce que le cache à l’origine du membre a reçu de son prochain saut. Il ne suffit pas à établir que ce saut était l’origine, que tous les caches ont ajouté un membre ou que la même décision a eu lieu ailleurs. Un champ peu fourni peut refléter un chemin court, une politique de confidentialité, une limite d’implémentation ou plusieurs de ces causes.

Conservez un reçu d’observation du cache. Il s’agit d’un contrôle opérationnel proposé ici, pas d’un objet de protocole défini par l’IETF. Préservez les octets bruts du champ et liez-les à la requête, à la réponse, au point d’observation et à l’heure. Pour chaque saut attendu, notez la politique d’émission, la correspondance des identifiants, les paramètres divulgués ou masqués, la trace de transfert, l’identité du prochain saut et les journaux concordants. Marquez les lacunes comme inconnues au lieu de transformer le silence en absence.

Ce reçu ne remplace pas Cache-Status; il maintient le champ dans son domaine de preuve. Un hit déclaré reste la preuve d’un hit local. Un transfert déclaré reste la preuve de l’action du cache concerné. Le registre supplémentaire répond à la question plus large: quelle part de la chaîne pouvait se déclarer, quelle part l’a fait et quelles preuves indépendantes ferment les intervalles?

Sources