Résumé

  • Cache-Groups permet à une réponse de déclarer des identifiants opaques et sensibles à la casse.
  • L’appartenance ne vaut que dans le même cache et pour la même origine URI.
  • Cache-Group-Invalidation doit être ignoré dans une réponse à une requête sûre; dans une requête non sûre, il peut invalider les réponses partageant les groupes nommés.
  • L’invalidation est facultative, sauf si une autre extension la rend plus forte, et elle ne se propage pas aux groupes nouvellement liés.

RFC 9875 ajoute au cache HTTP un moyen de nommer des ensembles de réponses apparentées. Une réponse stockée peut porter un ou plusieurs groupes. Ces chaînes sont opaques : leur interprétation dépend de la politique du cache et de l’origine. Elles sont aussi sensibles à la casse. La technique ne remplace donc pas une convention de propriété, une gestion des espaces de noms ou une autorisation explicite. Elle donne un signal exploitable dans un périmètre défini, non une identité globale pour des ressources distribuées.

La frontière du cache doit être écrite avant toute promesse opérationnelle. Deux caches indépendants ne partagent pas automatiquement leurs groupes. La réponse d’un cache ne devient pas une instruction de purge pour un autre, et le mécanisme n’associe pas des réponses provenant d’origines différentes. Il ne faut donc pas le présenter comme une synchronisation inter-cache, inter-CDN ou inter-origine. Même dans une architecture comportant plusieurs intermédiaires, chaque état local doit être considéré séparément.

La gestion du champ d’invalidation comporte une règle obligatoire et une option. Sur une requête sûre, Cache-Group-Invalidation doit être ignoré. Sur une requête non sûre, il peut invalider les réponses stockées qui partagent les groupes désignés. Le fait que l’opération soit possible ne la rend pas obligatoire : une autre extension peut renforcer cette sémantique, mais RFC 9875 seul ne crée pas une garantie universelle. De plus, le traitement ne cascade pas à travers des groupes devenus liés après coup.

Deux risques se font face. Une réponse apparentée peut rester périmée après une modification d’état. À l’inverse, un identifiant trop large peut toucher des contenus sans rapport. L’hébergement de plusieurs parties sous une même origine accentue le risque d’autorité : une partie pourrait se regrouper avec les ressources d’une autre ou les invalider si l’hébergeur ne maîtrise pas les accès. Les noms opaques ne constituent pas une isolation de sécurité; ils doivent être soutenus par des contrôles de production et d’interprétation.

La décision professionnelle consiste à définir qui possède les groupes, qui peut demander leur invalidation et dans quel cache cette action a un sens. Il faut annoncer la portée réelle, les comportements optionnels et les cas ignorés. Une architecture qui exige une convergence entre plusieurs caches doit disposer d’un mécanisme distinct, plutôt que d’étendre tacitement le signal local.

Sources