Zusammenfassung

  • RFC 9111 empfiehlt, must-understand mit no-store zu senden. Ein Cache, der die neue Direktive nicht kennt, ignoriert sie, erhält aber weiterhin eine verständliche konservative Anweisung.
  • Einen Status zu verstehen heißt nicht, seine Ziffern zu lesen. Der Cache muss ihn erkennen und das gesamte für ihn festgelegte Cache-Verhalten implementieren.
  • Die bedingte Ausnahme von no-store entfernt nur ein Hindernis. Methoden-, Autorisierungs-, Shared-Cache-, Speicher- und Wiederverwendungsregeln bleiben bestehen; auch Datenschutz entsteht dadurch nicht.

Zwei Generationen lesen dieselbe Antwort

Zwei Caches erhalten Cache-Control: must-understand, no-store.

Der erste stammt aus der Zeit vor must-understand. Nach den Erweiterungsregeln von HTTP muss er unbekannte Cache-Direktiven ignorieren. Er übergeht die erste, erkennt no-store und speichert die Antwort nicht.

Der zweite implementiert die neue Direktive. Das allein berechtigt ihn zu nichts. Er muss den Statuscode der Antwort erkennen und alle in dessen Spezifikation enthaltenen Cache-Anforderungen umgesetzt haben. Erst dann empfiehlt RFC 9111, das begleitende no-store zu ignorieren. Anschließend sind die übrigen Speicherbedingungen zu prüfen.

Diese Asymmetrie ermöglicht schrittweise Einführung. Der Origin-Server braucht kein vollständiges Inventar aller Vermittler. Alte Software erhält eine bekannte sichere Rückfallregel; neue Software wechselt aufgrund lokal belegter Fähigkeiten in einen anderen Zweig.

Wer nur must-understand zitiert, zerstört diese Logik. Der Name klingt wie ein universeller Befehl, doch ein Cache ohne Implementierung muss die Direktive gerade ignorieren. Fehlt no-store, fehlt ihm der vorgesehene Rückfall. Ausgerollt wird ein Paar, und die Eintrittskarte für den neuen Zweig ist nachgewiesenes Verhalten, nicht ein erkanntes Wort.

Verstehen ist eine Laufzeiteigenschaft

RFC 9111 definiert „verstanden“ präzise: Der Cache erkennt den Statuscode und implementiert sämtliches dafür spezifiziertes cachebezogenes Verhalten.

Ein Parser kann drei Ziffern akzeptieren. Eine Oberfläche kann den Namen anzeigen. Ein HTTP-Empfänger kann einen unbekannten Code nach seiner allgemeinen Klasse behandeln. Keine dieser Fähigkeiten beweist, dass der Cache die besondere Speicherregel anwendet.

Der Unterschied zeigt sich in den Normen. RFC 6585 verbietet die Speicherung von Antworten mit 428, 429, 431 und 511. RFC 7538 bezeichnet 308 Permanent Redirect dagegen grundsätzlich als cachefähig, sofern Methodensemantik oder ausdrückliche Kontrollen nichts anderes verlangen. Die Beispiele sind kein Gesamtkatalog; sie zeigen, dass Statuscodes unterschiedliche Ergebnisse verlangen.

Ein Produkt, das 429 korrekt benennt und dennoch wie eine gewöhnliche Antwort speichert, erkennt den Code, versteht ihn für RFC 9111 aber nicht. Auch ein Test, der nur den Parser für must-understand prüft, misst Syntax statt Konformität.

Ein belastbarer Nachweis trennt fünf Tatsachen: empfangener Status, Erkennung, Umsetzung seiner Cache-Vorgaben, Implementierung der Direktive und Ergebnis aller verbleibenden Speicher- und Wiederverwendungsbedingungen. Ein globales Feld „unterstützt“ ersetzt diese Beweiskette durch Selbstauskunft.

Das alte Verbot macht die Erweiterung sicher

Unbekannte Cache-Direktiven müssen ignoriert werden, damit Erweiterungen bereits ausgerollte Software nicht beschädigen. RFC 9111 beschreibt deshalb für verhaltensändernde Erweiterungen ein Doppel: neue und alte Direktive reisen gemeinsam. Unkundige Empfänger folgen dem alten Verhalten; kundige erkennen, wie die neue Regel es modifiziert.

no-store ist hier die alte Bremse. Es widerspricht must-understand nicht, sondern erzeugt den sicheren Standard. Nur der qualifizierte Cache kennt die enge Bedingung, unter der er die Bremse lösen darf.

Eine Auslassung verändert das Ergebnis. Bei must-understand allein ignoriert der alte Cache das einzige Signal. Vielleicht speichert er aus einem anderen Grund nicht, doch die Übergangsregel selbst schützt ihn nicht mehr.

RFC 9111 verwendet SHOULD sowohl für das Mitsenden von no-store als auch für dessen Ignorieren im qualifizierten Fall. Das ist eine starke normative Empfehlung, weder ein ausnahmsloser Befehl noch unverbindliche Dekoration. Wer abweicht, muss das Verhalten alter Teilnehmer erklären können.

Eine entfernte Sperre ist keine Speicherfreigabe

„no-store ignorieren“ bedeutet nicht „speichern“. Die Ausnahme streicht genau ein Verbot.

Weitere Bedingungen aus Abschnitt 3 bleiben: Die Methode muss Speicherung zulassen, der Status muss final sein, Autorisierungs- und Shared-Cache-Regeln können greifen, private gilt weiterhin und die Antwort braucht eine ausdrückliche oder statusbedingte Grundlage für Cachefähigkeit.

Wiederverwendung folgt als eigene Entscheidung. Ein gespeicherter Eintrag muss zur späteren Anfrage passen und frisch, erfolgreich validiert oder ausnahmsweise veraltet nutzbar sein. must-understand erzeugt keine Frische, validiert nichts und repariert keinen Cache-Schlüssel, der Benutzer vermischt.

Darum reicht must_understand=true im Protokoll nicht. Erforderlich sind Status und Referenz, Version und Testnachweis, beide Direktiven, die übrigen Prüfungen, die tatsächliche Speicherung und eine spätere Wiederverwendung als getrennte Ereignisse.

Register liefern Koordinaten, keine Softwarezertifikate

IANA führt Register für HTTP-Cache-Direktiven und Statuscodes. Sie liefern stabile Namen und verweisen auf die definierenden Dokumente. Sie bezeugen nicht die Konformität einer Installation.

Ein Eintrag für must-understand beweist keine Implementierung in einer Binärdatei. Ein registrierter Status beweist nicht, dass ein Cache seine Regeln kennt. Ein bestandener Test für einen Code lässt sich auch nicht auf künftige Codes übertragen.

Die Fähigkeit braucht ein kleines Dossier: Engine- und Modulversion, verwendete Definition, geprüfte Anforderungen und Resultate. Die Direktive schafft einen interoperablen Abzweig für diese Fähigkeit; sie erzeugt den Nachweis nicht.

Der Änderungsanhang von RFC 9111 erläutert, dass Caches neue Antwortstatus nicht mehr verstehen müssen, solange must-understand fehlt. Ein Origin kann also signalisieren, dass die besonderen Statusregeln für diese Antwort wesentlich sind. Er kann einen unbekannten entfernten Cache nicht für kompetent erklären.

Kein Datenschutzsiegel

RFC 9111 stellt klar, dass no-store kein zuverlässiger oder hinreichender Schutz der Privatsphäre ist. Bösartige oder kompromittierte Caches können die Direktive missachten; Kommunikationswege können abgehört werden. Die Kombination erweitert dieses Versprechen nicht.

Sie entscheidet auch nicht über Zugriffsrechte, Benutzertrennung in Shared Caches, Transportverschlüsselung oder Schutz auf Datenträgern. Wer den Header als Klassifizierungssiegel behandelt, verdrängt die Kontrollen, die diese Eigenschaften tatsächlich liefern.

Diese Untersuchung hat keine Anbieterimplementierung getestet und weder Verbreitung noch Vorfälle oder Lecks gemessen. Die Abläufe sind aus den Normen abgeleitete Gedankenexperimente.

Quellen und Beweisgrenze

Register und Errata sind Momentaufnahmen zum Recherchezeitpunkt. Die Quellen belegen Protokollregeln und die Governance-Deutung, nicht flächendeckende Produktunterstützung.