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

Eine Seite, die beim zweiten Besuch sofort da ist, wurde nicht noch einmal geholt, sondern kam aus einem Speicher irgendwo zwischen Server und Bildschirm – und ein Header hat das erlaubt.

Diese Zeile heißt Cache-Control – kurz, gebaut aus Wörtern, die selbsterklärend aussehen, und zwei davon bedeuten beinahe Gegensätzliches, obwohl sie wie Synonyme klingen.

Zwei Speicher, nicht einer

Zwischen Server und Bildschirm gibt es meist zwei Orte, an denen eine Antwort liegen bleiben kann.

Der erste ist der Browser auf einem Gerät. Was dort liegt, dient genau einer Person und bleibt, bis es abläuft oder gelöscht wird.

Der zweite ist ein gemeinsamer Speicher: ein CDN, ein Firmen-Proxy, irgendetwas im Weg, das viele Menschen aus einer Kopie bedient. Er ist der wirksamere von beiden, weil eine gespeicherte Kopie tausende Anfragen spart – und der gefährlichere, weil eine persönliche Seite, die dort landet, an die Falschen ausgegeben wird.

Fast jedes Missverständnis übers Zwischenspeichern kommt daher, dass der zweite Speicher vergessen wird. Angaben, die sich zu widersprechen scheinen, sprechen meist verschiedene Speicher an.

no-cache und no-store sind nicht zweimal dasselbe Wort

Die beiden sehen aus wie ein Paar und sind keins.

no-store heißt: nichts aufbewahren. Keine Kopie irgendwo, weder im Browser noch in einem gemeinsamen Speicher noch auf einer Platte. Jede Anfrage geht zum Server zurück. Das ist die Angabe für einen Kontoauszug.

no-cache heißt: aufbewahren, aber vor der Verwendung nachfragen. Die Kopie wird ganz normal gespeichert; der Browser darf sie nur nicht ohne Rückfrage ausliefern. Antwortet der Server, dass sich nichts geändert hat, wird die gespeicherte Kopie verwendet, und es fließt kein Inhalt.

no-cache bedeutet also nicht „nicht zwischenspeichern”. Es bedeutet „zwischenspeichern, aber jedes Mal nachfragen” – und es gibt diese Angabe gerade deshalb, um Zwischenspeichern für Seiten möglich zu machen, die sich unvorhersehbar ändern. Eine kurze Rückfrage kostet einen Bruchteil einer vollen Übertragung.

Wer no-store schreibt und no-cache meint, verschenkt diese Ersparnis bei jeder einzelnen Anfrage. Wer no-cache schreibt und no-store meint, hinterlässt eine Kopie von etwas Vertraulichem auf einer Platte.

Zwei Zahlen für zwei Speicher

max-age ist die Lebensdauer in Sekunden. s-maxage ist dasselbe, aber nur für gemeinsame Speicher, und dort sticht es max-age aus.

Die Startseite von Wikipedia zeigt, wozu es beide gibt. Der Header dort lautet s-maxage=86400, must-revalidate, max-age=3600: das CDN darf die Seite einen ganzen Tag behalten, ein Browser eine Stunde. Der teure Speicher hält sie lange, der persönliche kurz – und eine Zeile regelt beides.

Ohne s-maxage folgt der gemeinsame Speicher schlicht dem max-age. Das ist der Normalfall, und deshalb hält ein CDN eine Seite manchmal weit länger oder kürzer als gedacht: für ihn wurde keine eigene Zahl geschrieben.

must-revalidate vervollständigt das Bild. Ist die Lebensdauer abgelaufen, darf die gespeicherte Kopie nicht mehr verwendet werden, auch nicht kurz, auch nicht bei unerreichbarem Server. Ohne diese Angabe hat ein Speicher mit einer abgelaufenen Kopie einen gewissen Spielraum.

Wer überhaupt speichern darf

private und public beschreiben nicht den Inhalt, sondern benennen den Speicher.

private heißt: nur der Browser einer Person. Gemeinsame Speicher dürfen diese Antwort nicht behalten. Das ist die richtige Einstellung für alles, was einen Namen, einen Warenkorb oder einen Kontostand zeigt – alles, was für einen einzelnen Besuch zusammengesetzt wurde.

public heißt: gemeinsame Speicher dürfen ebenfalls behalten. Es hebt außerdem ein paar Regeln auf, die sonst gegen das Zwischenspeichern sprächen, und steht deshalb auch auf Seiten, die ohnehin problemlos speicherbar wären.

Der Fehler ist hier leise und ernst: eine persönliche Seite ohne private, hinter einem CDN, wird einmal gespeichert und dem nächsten Besuch samt fremdem Namen vorgesetzt. Nichts stürzt ab, nichts wird protokolliert, und die Seite sieht richtig aus – für die falsche Person.

Die veralteten Antworten, die mit Absicht ausgeliefert werden

Zwei Zusätze erlauben einem Speicher, eine abgelaufene Kopie bewusst auszuliefern, und beide lassen Seiten schneller wirken, als sie sind.

stale-while-revalidate sagt: ist die Kopie gerade eben abgelaufen, gib sie trotzdem heraus und hol im Hintergrund eine frische. Der Besuch wartet auf nichts; der nächste bekommt die neue Fassung.

stale-if-error sagt: ist der Server nicht erreichbar, liefere lieber die alte Kopie als eine Fehlerseite. Eine Seite mit dieser Angabe übersteht einen kurzen Ausfall, ohne dass es jemand bemerkt.

Die Startseite der BBC verwendet beides, mit 30 und 90 Sekunden. GitHub schickt dagegen max-age=0, private, must-revalidate – nichts wird ohne Rückfrage ausgeliefert, denn eine Repository-Seite darf keine Sekunde veraltet sein.

Keines von beidem ist richtiger. Es sind verschiedene Antworten auf dieselbe Frage: was ist hier schlimmer, eine langsame Seite oder eine alte.

Was ein Header zeigt

Die Zeile kommt mit jeder Antwort mit, und sie zu lesen kostet eine Anfrage.

Vier Fragen lohnen sich. Ist no-store gemeint oder no-cache – nichts behalten, oder behalten und nachfragen. Trägt eine persönliche Seite ein private. Gibt es ein eigenes s-maxage für den gemeinsamen Speicher, oder erledigt eine Zahl stillschweigend beide Aufgaben. Und ist die Lebensdauer plausibel dafür, wie oft sich der Inhalt tatsächlich ändert.

Der HTTP-Security-Header-Prüfer liest die Header einer beliebigen Adresse so, wie ein Browser sie liest, und verfolgt dabei die Weiterleitungen.

Die brauchbare Antwort ist ein Satz: ob diese Seite dort gespeichert wird, wo sie soll, und so lange, wie sie soll – und von niemandem sonst.