Cache-Control-Direktiven: max-age, no-store, private und stale-while-revalidate

Worum es geht

RFC 9111 definiert die Antwort-Direktiven, die ein Cache befolgen MUSS:

• max-age=N: Die Antwort gilt als veraltet, sobald ihr Alter N Sekunden überschreitet. s-maxage=N überschreibt dies für Shared Caches und verlangt von ihnen zusätzlich eine Revalidierung, sobald sie veraltet ist.
• no-cache: Die Antwort DARF NICHT zur Beantwortung einer weiteren Anfrage verwendet werden, ohne sie zuerst zur Validierung weiterzuleiten. Das Speichern wird dadurch nicht verboten; eine gespeicherte Kopie plus ein Validator machen die Revalidierung günstig.
• no-store: Der Cache DARF KEINEN Teil der Anfrage oder Antwort speichern. RFC 9111 stellt fest, dass dies kein zuverlässiger oder ausreichender Mechanismus ist, um Datenschutz sicherzustellen.
• private: Ein Shared Cache DARF die Antwort NICHT speichern; public markiert sie explizit als cachefähig, etwa eine Antwort auf eine Anfrage, die Authorization trug.
• must-revalidate: Ist die Antwort einmal veraltet, DARF sie NICHT ohne erfolgreiche Validierung wiederverwendet werden; ein vom Netz getrennter Cache muss einen Fehler zurückgeben (vorgeschlagen wird 504).
• immutable (RFC 8246): Clients sollen während der Frischedauer keine bedingten Anfragen senden, auch nicht beim Neuladen.
• stale-while-revalidate=N und stale-if-error=N (RFC 5861): Caches dürfen die veraltete Antwort für weitere N Sekunden ausliefern, während sie im Hintergrund revalidieren oder während der Ursprungsserver Fehler zurückgibt.

Fehlt jede explizite Frischeangabe, DARF ein Cache für heuristisch cachefähige Statuscodes eine heuristische Lebensdauer berechnen; RFC 9111 nennt einen Bruchteil des Intervalls seit Last-Modified, typischerweise 10 %.

Warum es wichtig ist

Schweigen bedeutet nicht „nicht cachen“: Ein einfaches 200 mit Last-Modified kann für eine heuristische Dauer wiederverwendet werden. no-cache wird regelmässig mit no-store verwechselt, und public auf einer personalisierten Antwort lässt sie über ein CDN durchsickern. Die Direktiven sind der Vertrag zwischen Ursprungsserver, CDN und Browser; eine falsche lässt sich schwer zurücknehmen, weil die zwischengespeicherte Kopie die Korrektur überlebt.

So wird es angewendet

• Versionierte statische Assets: public, max-age=31536000, immutable; die URL ändern, wenn sich der Inhalt ändert.
• Sich ändernde HTML- und API-Antworten: no-cache (oder max-age=0, must-revalidate) plus ein ETag, sodass die Revalidierung nur ein 304 kostet.
• Nutzerspezifische Antworten: private mit einem kurzen max-age, oder no-store, wenn die Speicherung auf gemeinsam genutzten Rechnern bedenklich ist.
• Sich langsam ändernde öffentliche Daten: max-age=60, stale-while-revalidate=600, stale-if-error=86400, kombiniert mit einem Validator.
• Bei ausgehandeltem Inhalt immer explizite Direktiven und Vary senden; den Age-Header von CDN-Antworten lesen, um zu sehen, wie alt eine Kopie ist.

Stolpersteine

Caches MÜSSEN unbekannte Direktiven ignorieren, sodass stale-while-revalidate bei Caches, die älter als diese Direktive sind, zum normalen Verhalten zurückfällt. Die qualifizierten Formen no-cache="Set-Cookie" und private="..." werden in RFC 9111 als nicht weit verbreitet implementiert beschrieben. max-age zählt ab dem Erzeugungszeitpunkt beim Ursprungsserver, wie er sich in Age ansammelt, nicht ab dem Empfang. Anfrage-Direktiven (max-stale, only-if-cached) kommen vom Client und sind eine eigene Liste.

Personalisierte Antworten und Shared Caches

no-cache erlaubt die Speicherung; es erzwingt lediglich eine Revalidierung vor der Wiederverwendung. Ein Shared Cache kann deshalb eine per Cookie authentifizierte Antwort speichern und sie bei der Anfrage der nächsten Person mit dem ETag der ersten Person revalidieren; antwortet der Ursprungsserver mit 304 allein aufgrund des Tag-Vergleichs, liefert der Cache den Body einer Person an eine andere aus. Standardmässig sind nur Antworten auf Anfragen mit Authorization von Shared Caches ausgeschlossen. Jede Antwort, die davon abhängt, wer anfragt, als private kennzeichnen (oder no-store, wenn auch die Speicherung auf dem Gerät unerwünscht ist), no-cache und den ETag für günstige Browser-Revalidierung beibehalten und die 304-Entscheidung sowohl von der authentifizierten Instanz als auch vom Tag abhängig machen. no-cache allein nur für Inhalte verwenden, die für jede anfragende Partei identisch sind.