Zusammenfassung

  • RFC 9111 verpflichtet einen Cache nach einer fehlerfreien Antwort auf eine unsichere Anfrage zur Invalidierung des Ziel-URI; die Regel gilt jedoch für die Caches, die diese Anfrage durchlaufen hat.
  • Wer eine globale Bereinigung behauptet, benötigt zusätzliche Nachweise für Pfadabdeckung, verwandte URI-Identitäten und anwendungsspezifische abgeleitete Schlüssel.

Nehmen wir einen ausdrücklich hypothetischen Vorfall. Ein Client sendet ein PUT, der Origin antwortet mit 204 No Content, und ein Kontrollfeld meldet sofort die globale Bereinigung als abgeschlossen. Die Schreiboperation lief durch einen Anwendungscache und ein regionales Gateway. Ein außerhalb dieses Pfades liegender Edge-Cache liefert dennoch eine aus dem alten Objekt zusammengesetzte Sammlungsseite aus. Weder dieser Edge noch der abgeleitete Sammlungsschlüssel gehen aus dem Status 204 hervor.

Das ist kein Mangel des HTTP-Cachings. Es ist die Grenze zwischen einer Protokollregel und einer Betriebsaussage. RFC 9110 bezeichnet eine Methode als sicher, wenn ihre definierte Semantik im Wesentlichen schreibgeschützt ist; GET, HEAD, OPTIONS und TRACE gelten als sicher. Zustandsverändernde Methoden werden anders behandelt. RFC 9111 verlangt, dass ein Cache unsichere Anfragen zum Origin durchschreibt. Er darf keine Antwort erzeugen, bevor er die Anfrage weitergeleitet und die zugehörige Antwort erhalten hat.

Diese Antwort löst eine präzise Pflicht aus. Erhält ein Cache eine fehlerfreie Antwort auf eine unsichere Methode, muss er den Ziel-URI invalidieren. Fehlerfrei bedeutet in diesem Zusammenhang einen 2xx- oder 3xx-Status. Invalidierung kann die passenden gespeicherten Antworten entfernen oder sie als ungültig markieren, sodass vor einer Wiederverwendung zwingend validiert werden muss. Die Regel verhindert eine ungeprüfte Nutzung; sie bestätigt nicht, dass jede Kopie im System verschwunden ist.

RFC 9111 gestattet außerdem die Invalidierung weiterer URIs. Location und Content-Location können Kandidaten liefern, sofern sie denselben Origin wie der Ziel-URI haben. Diese Möglichkeit ist nützlich, aber keine universelle Abhängigkeitserkennung. Ein Cache darf nach dieser Regel keinen Kandidaten eines anderen Origins invalidieren. Er muss auch nicht jede Produktseite, Liste, Suche, jedes Fragment oder jeden Surrogate Key herleiten, den die Anwendung aus dem geänderten Objekt erzeugt.

Die Topologie setzt eine weitere Grenze. Die Spezifikation weist ausdrücklich darauf hin, dass der Mechanismus keine globale Invalidierung garantiert: Eine zustandsverändernde Anfrage invalidiert Antworten nur in den Caches, die sie durchläuft. Ein Cache auf einem anderen Lesepfad hat kein Protokollereignis erhalten, das seine lokale Pflicht auslöst. Multi-CDN-Betrieb, umgangene Shields, regionale Partitionen und getrennte API- und Seitenpfade machen daraus ein Kontrollproblem.

Häufig werden drei Aussagen vermischt. „Der Origin hat die Schreiboperation angenommen“ beschreibt die Antwort. „Ein durchlaufener Cache hat den Ziel-URI invalidiert“ beschreibt eine vorgeschriebene lokale Handlung. „Jeder Leser sieht jetzt den neuen Zustand“ betrifft Topologie, Schlüsselableitung und Verifikation. Die erste Aussage belegt die zweite nicht auf jeder Ebene; beide zusammen belegen die dritte noch nicht.

Die Lücke lässt sich mit einem Invalidierungspfad-Beleg schließen. Dabei handelt es sich um ein hier vorgeschlagenes redaktionelles Kontrollinstrument, nicht um ein vom IETF definiertes Protokollobjekt. Der Beleg verbindet die unsichere Anfrage und ihre Antwort mit den Cache-Instanzen, die sie transportiert haben; hält den normalisierten Ziel-URI und die lokale Handlung fest; trennt die obligatorische Zielinvalidierung von der optionalen Behandlung von Location und Content-Location; ergänzt die Abbildung auf Sammlungen, Suchen, Fragmente und Surrogate Keys; und bewahrt Cache-umgehende Prüfungen aus jedem wesentlichen Auslieferungspfad auf.

Damit ändert sich die Frage nach einer erfolgreichen Schreiboperation. Ein 204 wird nicht als globales Cache-Ereignis behandelt. Gefragt wird, welcher Pfad die Änderung trug, welcher Cache handelte, welche Identitäten abgedeckt wurden und welche unabhängigen Lesevorgänge den neuen Zustand belegten. Erst dann wird aus einer protokollkonformen lokalen Handlung ein Nachweis für eine systemweite Aussage.

Quellen