Résumé

  • Un cache qui prend en charge les champs ciblés choisit le premier champ valide et non vide de sa liste ordonnée ; un cache qui ne cible pas ce champ ne doit pas modifier son comportement à cause de lui.
  • Une même réponse peut donc être stockée, refusée ou régie par un autre champ selon l’étape, même si CDN-Cache-Control est syntaxiquement correct.

Prenons un déploiement volontairement hypothétique. L’origine envoie Cache-Control: no-store et CDN-Cache-Control: max-age=600. Le premier CDN reconnaît le champ ciblé et conserve la réponse pendant dix minutes. Un cache d’entreprise situé en aval ne place pas ce champ dans sa liste et respecte no-store. Un second CDN donne priorité à un champ propre au fournisseur, placé avant CDN-Cache-Control. Pourtant, le tableau de bord inscrit un résultat unique : « politique de cache : 600 secondes ».

L’en-tête ne ment pas. C’est le tableau de bord qui a supprimé le mécanisme de décision donnant son sens au champ.

La RFC 9213 définit un champ de contrôle de cache ciblé comme un champ de réponse dont le nom distinct désigne le cache ou la classe de caches visés. CDN-Cache-Control en est l’exemple normalisé. Sa valeur reprend la sémantique des directives de cache, mais le cache qui l’implémente possède aussi une liste ordonnée de cibles. Cette liste peut être fixe, configurable ou produite pour chaque requête. Lorsque plusieurs champs reconnus sont présents, le cache choisit le premier qui soit valide et non vide dans cet ordre.

Ce choix a un effet fort. Après avoir sélectionné un champ ciblé, le cache utilise sa valeur pour déterminer la politique de la réponse et ignore Cache-Control ainsi qu’Expires pour cette réponse. Si aucun champ de sa liste n’est présent avec une valeur valide et non vide, il revient aux mécanismes HTTP ordinaires de la RFC 9111. Deux caches conformes peuvent donc recevoir les mêmes octets et prendre des décisions différentes parce que leurs listes diffèrent.

La portée compte autant que la priorité. Un champ ciblé absent de la liste d’un cache ne doit pas influer sur son comportement et doit être transmis. Un cache non CDN peut voir CDN-Cache-Control sans l’appliquer. Inversement, un CDN qui l’applique transmet normalement le champ aux CDN situés en aval, mais la RFC 9213 autorise sa suppression lorsque cette transmission n’est pas souhaitable. Le champ observé à un point donné ne prouve donc pas ce que chaque étape précédente ou suivante a reçu.

L’analyse syntaxique forme une autre frontière. Les champs ciblés sont des dictionnaires Structured Fields. Leur apparence ressemble souvent à Cache-Control, mais leur traitement des erreurs n’est pas interchangeable. Un champ vide ou invalide est ignoré, ce qui peut activer une politique de repli. Un outil qui conserve la chaîne de caractères sans le verdict de l’analyseur peut attribuer un comportement à un champ que le cache n’a jamais accepté.

La fraîcheur reste elle aussi relative au cache qui sélectionne la politique. L’exemple de la RFC 9213 permet à un CDN de considérer une réponse fraîche pendant 3 600 secondes, aux autres caches partagés pendant 600 secondes et aux caches restants pendant 60 secondes. Au bout de 1 800 secondes, la réponse est fraîche pour le CDN et périmée ailleurs. Il n’y a pas de contradiction, mais des politiques applicables différentes. L’erreur opérationnelle consiste à les réduire à un état unique.

Cette réduction peut devenir une erreur de sécurité. La RFC 9213 avertit que plusieurs politiques portées par une même réponse peuvent créer de la confusion et une réutilisation involontaire de données sensibles. Un test réussi à l’origine prouve que les champs voulus ont été émis ; il ne prouve ni quels caches les reconnaissent, ni quel champ chacun choisit, ni si l’analyse a réussi, ni si un champ a été supprimé, ni si la réutilisation respecte la limite attendue.

L’unité de preuve utile est donc une fiche de décision de cache par étape. Pour chaque cache important, il faut relier classe et identité, liste ordonnée de cibles, champs exactement reçus, résultat de l’analyse, champ choisi, directives effectives, données de fraîcheur, chemin de repli, action de transmission ou de suppression et observation du stockage ou de la réutilisation. Les étapes inconnues doivent rester explicites.

Cette fiche est un contrôle opérationnel éditorial, non un objet défini par l’IETF. Elle empêche qu’un champ valide soit transformé en affirmation injustifiée sur toute la chaîne.

Sources