Cache-Control einfach erklärt: Was no-cache, no-store, max-age und s-maxage jeweils bewirken

Cache-Control beschreibt, ob eine HTTP-Antwort gespeichert und wann eine gespeicherte Antwort erneut verwendet werden darf. Ein schneller zweiter Seitenaufruf belegt weder einen Cachetreffer noch das Ausbleiben einer Netzwerkanfrage.

Der zentrale Unterschied: no-store verbietet die Speicherung in HTTP-Caches; no-cache erlaubt die Speicherung, verlangt aber vor der Wiederverwendung eine erfolgreiche Validierung. Keine der beiden Angaben garantiert, dass andere Anwendungsteile keine Daten aufbewahren.

Speicherung und Frische unterscheiden

Ein privater HTTP-Cache liegt beispielsweise im Browser. Gemeinsame Caches, etwa ein CDN oder Proxy, bedienen mehrere Clients. Mehrere Cacheebenen sind möglich. „Privat“ bezeichnet die Cacheart und garantiert keinen exklusiven Gerätezugang für genau eine Person.

Validierung bedeutet eine Rückfrage beim Server: Ist die gespeicherte Antwort noch aktuell? Eine frische Antwort darf unter Beachtung der übrigen Cacheregeln normalerweise ohne diese Rückfrage erneut verwendet werden. Eine veraltete Antwort hat diese Frischefrist überschritten. Veraltet bedeutet nicht gelöscht: Für eine spätere Validierung kann die Antwort gespeichert bleiben. Umgekehrt kann Platzmangel schon vor Fristende zur Verdrängung führen.

no-cache: vor der Wiederverwendung prüfen

Bei der Antwortangabe Cache-Control: no-cache ohne Feldliste müssen private und gemeinsame Caches vor der Wiederverwendung erfolgreich validieren. Die Speicherung bleibt optional.

Ein ETag kann als If-None-Match zurückgesendet werden; Last-Modified ermöglicht eine Prüfung über If-Modified-Since. Eine passende Antwort 304 Not Modified spart die erneute Übertragung des Antwortkörpers. Anfrage und Antwortheader werden weiterhin übertragen. Geänderter Inhalt erfordert normalerweise einen neuen Antwortkörper. Die Ersparnis hängt von Inhaltsgröße und Prüfaufwand ab.

no-store: eine Regel für HTTP-Caches

Cache-Control: no-store untersagt HTTP-Caches, diese Antwort zu speichern. Eine neu gesetzte Angabe am Ursprungsserver löscht keine alten Cacheeinträge aus der Ferne, solange kein erneuter Serverkontakt stattfindet.

Eine allgemeine Lösch- oder Vertraulichkeitsgarantie entsteht daraus nicht. Anwendungsspeicher und die JavaScript-Cache-API brauchen eigene Regeln; die Cache-API beachtet HTTP-Cacheheader nicht automatisch. Auch der Zurück-/Vorwärts-Cache speichert Seitenzustand nach gesonderten Browserregeln. Chrome kann bestimmte Seiten trotz no-store unter festgelegten Voraussetzungen dort aufnehmen.

max-age und s-maxage bestimmen die Frischefrist

max-age legt die Frischefrist in Sekunden fest. s-maxage gilt für gemeinsame Caches und hat dort Vorrang vor max-age und Expires. Das folgende konstruierte Beispiel betrifft öffentlich nutzbare, nicht personalisierte Inhalte:

Cache-Control: public, max-age=60, s-maxage=300

Im Browser beträgt die Frischefrist 60 Sekunden, im gemeinsamen Cache 300 Sekunden. Eine garantierte Aufbewahrungsdauer ergibt sich daraus nicht. Bereits in Caches verbrachte Zeit zählt zum Antwortalter. Bei max-age=300 und Age: 180 bleiben ungefähr 120 Sekunden, abzüglich weiterer Übertragungs- und Aufenthaltszeit.

must-revalidate verbietet nach Ablauf der Frischefrist die Wiederverwendung bis zur erfolgreichen Validierung, auch bei einem Ausfall des Ursprungsservers. s-maxage enthält diese Einschränkung für gemeinsame Caches ebenfalls. Fehlende Angaben erlauben keine beliebig lange Auslieferung veralteter Inhalte.

private und public legen den Cachebereich fest

private ohne Feldliste verbietet gemeinsame Speicherung, erlaubt aber unter den übrigen Regeln einen privaten Cache. Für eine persönliche Antwort, die lokal gespeichert, vor erneuter Verwendung jedoch geprüft werden muss, kommt beispielsweise diese Kombination infrage:

Cache-Control: private, no-cache

Soll bereits die HTTP-Speicherung unterbleiben, ist no-store die passende Einschränkung. public kann gemeinsame Speicherung erlauben, erzwingt aber keine Speicherung und hebt ein gleichzeitiges Verbot wie no-store nicht auf. Keine dieser Angaben ersetzt Anmeldung oder Berechtigungsprüfung.

Ein falsch eingerichteter gemeinsamer Cache kann persönliche Antworten offenlegen. Das Risiko hängt von Cacheschlüsseln, Cookies, Anmeldung und CDN-Regeln ab; fehlendes private allein beweist noch kein Datenleck. Anbieterregeln können Cachevorgaben des Ursprungsservers überschreiben. Deshalb zählen Konfiguration und tatsächliche Antworten gemeinsam.

Veraltete Antworten brauchen klare Grenzen

Für öffentliche Inhalte mit vertretbarer kurzer Verzögerung eignet sich als weiteres konstruiertes Beispiel:

Cache-Control: public, max-age=60, stale-while-revalidate=30, stale-if-error=90

Ein unterstützender Cache darf die veraltete Antwort bis zu 30 zusätzliche Sekunden ausliefern und währenddessen eine Validierung im Hintergrund versuchen. Eine Anfrage stößt diesen Vorgang an. Weder eine erfolgreiche Aktualisierung noch eine frische Antwort beim nächsten Aufruf ist garantiert.

stale-if-error=90 erlaubt bei einem passenden Fehler eine bis zu 90 Sekunden veraltete Antwort; dazu zählen HTTP 500, 502, 503 und 504. Das ist eine begrenzte Ausweichmöglichkeit, kein unbegrenzter Ausfallschutz. Ein Anwendungsfehler mit HTTP 200 gehört nicht zu diesen Fehlercodes. Unterstützung und Zusammenspiel mit strengeren Angaben hängen vom Cache ab; das Beispiel enthält bewusst weder must-revalidate noch s-maxage.

Was ein Headercheck nachweisen kann

Der HTTP-Security-Header-Prüfer ruft die Adresse serverseitig ab und folgt Weiterleitungen innerhalb seiner Grenzen. Eine angemeldete Browsersitzung wird damit nicht nachgebildet. Eine einzelne Antwort belegt weder tatsächliche Speicherung noch getrennte Cacheschlüssel oder das Verhalten aller CDN-Standorte. Cache-Control kann außerdem fehlen; dann können andere Regeln greifen oder Fristen anhand vorhandener Antwortinformationen geschätzt werden.

Eine belastbare Prüfung verbindet Antwortheader, Browser-Netzwerkbeobachtung und CDN-Konfiguration. Dazu gehören Status, Age, Vergleichswerte, verwendeter Cacheschlüssel und die Herkunft einer wiederholten Antwort aus Arbeitsspeicher, Festplatte oder Netzwerk. Antworten ohne Anmeldung und mit Anmeldung brauchen getrennte Prüfungen. Mehrfach vorkommende Headerfelder sollten in der ursprünglichen Netzwerkantwort statt ausschließlich in einer zusammengefassten Werkzeuganzeige geprüft werden.