Zusammenfassung

  • Cache-Groups verbindet nur Antworten desselben Ursprungs, die im selben Cache liegen und dieselbe groß-/kleinschreibungssensitive Zeichenfolge tragen.
  • Cache-Group-Invalidation ermöglicht nach einer unsicheren Anfrage eine optionale lokale Entscheidung; sie kaskadiert nicht und synchronisiert keinen zweiten Cache.

Ein geänderter Datensatz kann eine Detailseite, eine Suche und eine Zusammenfassung betreffen, obwohl jede Antwort eine andere URI und einen anderen Cache-Schlüssel hat. RFC 9875 gibt dem Ursprung ein standardisiertes Mittel, diese Beziehung zu benennen, ohne die Antworten semantisch gleichzusetzen.

Cache-Groups ist eine List aus Strings nach Structured Fields. Für den Cache bleibt der String undurchsichtig: Er vergleicht ihn, liest aber weder Hierarchie noch Geschäftslogik oder Berechtigung hinein. Die Reihenfolge ist bedeutungslos, unbekannte Parameter werden ignoriert. Implementierungen müssen mindestens 32 Gruppen pro Feld und mindestens 32 Zeichen je Mitglied unterstützen; allgemeine HTTP-Feldgrenzen gelten weiter.

Gruppengleichheit verlangt drei Bedingungen: Beide Antworten befinden sich im selben Cache, ihre Strings stimmen Zeichen für Zeichen unter Beachtung der Groß- und Kleinschreibung überein, und sie gehören zum selben URI-Ursprung. Derselbe Name an einem anderen Ursprung ist keine Mitgliedschaft. Derselbe Name in einem anderen Cache erzeugt ebenfalls keinen gemeinsamen Zustand.

Cache-Group-Invalidation wird in der Antwort auf eine potenziell zustandsändernde Anfrage ausgewertet, etwa POST, PUT oder DELETE. Das Feld nennt Gruppen, die der empfangende Cache invalidieren darf. In der Antwort auf eine sichere Methode wie GET muss es ignoriert werden. Anfrageart und Antwortkontext gehören deshalb in den Beleg.

Entscheidend ist MAY. Der Cache darf verwandte Mitglieder invalidieren, doch RFC 9875 verpflichtet nicht jeden Vermittler zu derselben Handlung. RFC 9213 kann Regeln gezielt an Cache-Klassen richten und dadurch die Vorgabe verstärken. Welches Profil galt, ist ein eigener Konfigurationsnachweis.

Invalidierung ist nicht zwingend Löschung. Nach RFC 9111 kann der Cache gespeicherte Antworten entfernen oder als ungültig markieren, sodass vor der nächsten Nutzung zwingend validiert werden muss. Der lokale Ereignisbeleg sagt damit noch nicht, ob Bytes verschwanden, eine Validierung erfolgreich war oder eine geänderte Darstellung nachgeladen wurde.

Auch eine transitive Ausbreitung ist ausgeschlossen. Teilt A eine Gruppe mit B und B eine andere mit C, läuft die Invalidierung von A nicht über B bis C. Gruppierte Invalidierungen lösen keine weiteren gruppierten Invalidierungen aus. Maßgeblich ist der Bestand dieses Caches zum Verarbeitungszeitpunkt.

Die wichtigste Grenze ist topologisch. Der Mechanismus wirkt innerhalb eines einzelnen Caches und bei Antworten eines einzelnen Ursprungs. Er synchronisiert weder Hierarchien noch Meshes und verbindet keine verschiedenen Ursprünge. Ein Edge-Knoten kann das Signal erhalten, während ein anderer Pfad es nie sieht.

Ein belastbarer Nachweis trennt daher Ursprungskonfiguration, Berechtigung zur Feldausgabe, Methode und Antwort, Empfang an jedem Vermittler, Implementierungsunterstützung, lokale Richtlinie, damalige Mitgliedschaft, Entscheidung, Löschung oder Markierung, spätere Validierung oder Befüllung und den Anwendungscanary je relevantem Pfad. Kein Schritt beweist automatisch den nächsten.

Beim Shared Hosting wird die Ausgabeberechtigung zum Sicherheitsproblem. RFC 9875 warnt, dass eine Partei Ressourcen mit denen einer anderen Partei am selben Ursprung gruppieren oder Signale mit Nebenwirkungen senden könnte. Die Plattform muss das Einfügen und Weiterreichen der Felder nach Mandant und Ursprung begrenzen.

Das IANA-Register der HTTP-Feldnamen führt beide Felder als permanente Lists. Die Registrierung belegt gemeinsame Namen und Referenzen, nicht Unterstützung, Weitergabe, Verarbeitung oder Produktionsergebnis.

Quellen