Zusammenfassung

  • Cache-Groups erlaubt eine oder mehrere undurchsichtige, groß- und kleinschreibungssensitive Gruppenzeichenfolgen.
  • Die Mitgliedschaft gilt nur innerhalb desselben Caches und desselben URI-Ursprungs.
  • Cache-Group-Invalidation in einer Antwort auf eine sichere Anfrage muss ignoriert werden; bei einer unsicheren Anfrage darf es gespeicherte Antworten mit den genannten Gruppen invalidieren.
  • Invalidierung ist optional, sofern keine andere Erweiterung sie verstärkt, und sie kaskadiert nicht durch später entstehende Gruppenbeziehungen.

RFC 9875 fügt dem HTTP-Caching ein Vokabular für zusammengehörige gespeicherte Antworten hinzu. Eine Antwort kann eine oder mehrere Gruppen deklarieren. Der Cache kann diese Deklarationen nutzen, um verwandte Antworten im eigenen Zustandsraum zu betrachten. Die Werte sind undurchsichtig und unterscheiden Groß- und Kleinschreibung. Daraus folgt: Der Standard definiert weder den geschäftlichen Sinn eines Namens noch dessen Besitzer. Namespace, Ausgabeerlaubnis und Invalidierungsautorität müssen außerhalb dieser Syntax geregelt werden.

Die Cache-Grenze ist die erste Sicherheits- und Betriebsgrenze. Eine Gruppe in einem Cache wird nicht automatisch in einem zweiten Cache bekannt. Browser, Proxies und andere Intermediäre können getrennte Zustände besitzen. Ebenso ordnet der Mechanismus keine Antworten verschiedener URI-Ursprünge ein. Er ist deshalb weder eine Synchronisierung zwischen Caches noch eine Cross-CDN- oder Cross-Origin-Steuerung. Eine lokale Beobachtung darf nicht als Nachweis globaler Konvergenz ausgegeben werden.

Bei der Feldbehandlung muss zwischen Pflicht und Option unterschieden werden. Bei einer sicheren Anfrage muss ein Cache-Group-Invalidation-Feld ignoriert werden. Bei einer unsicheren Anfrage darf es gespeicherte Antworten invalidieren, die die benannten Gruppen teilen. Das ist ohne verstärkende Erweiterung keine zwingende Invalidierung. Außerdem gibt es keine automatische Kaskade in Gruppen, die erst durch weitere Beziehungen verbunden wurden.

Damit entstehen zwei entgegengesetzte Fehlerbilder. Nach einer Zustandsänderung können verwandte Antworten veraltet bleiben. Ein zu weiter Gruppenname kann umgekehrt Inhalte eines anderen Mandanten treffen. Bei Hosting unter einem gemeinsamen Ursprung besteht ein Autoritätsrisiko: Eine Partei könnte sich mit Ressourcen einer anderen gruppieren oder diese invalidieren, wenn der Host den Zugriff nicht kontrolliert. Undurchsichtige Namen sind keine Mandantentrennung.

Die technische Entscheidung lautet daher nicht, einen Header als globale Löschfunktion zu behandeln. Zu bestimmen sind der konkrete Cache, der URI-Ursprung, die Gruppenbesitzer und die Instanz mit Invalidierungsbefugnis. Benötigt ein System mehrere Cache-Zustände, braucht es dafür ein separates Synchronisationsdesign. RFC 9875 darf nicht stillschweigend über seine lokale Reichweite hinaus interpretiert werden.

Quellen