Wählen Sie Direktiven aus oder fügen Sie einen vorhandenen Header ein. Geprüft wird der Headertext, nicht das Verhalten eines Live-Caches.
Läuft lokal in deinem BrowserDas obere Feld stellt eine Response-Richtlinie zusammen: Sichtbarkeit wählen, eine Frischefrist in Sekunden eintragen, die benötigten Direktiven ankreuzen und auf Header erstellen klicken. Der Header, den die Seite senden würde, erscheint im Feld Response-Header mit einer dreizeiligen Übersicht — Anzahl der Direktiven, Frische der Antwort, erlaubter Cache-Bereich — und darunter jedem Konflikt, den die Kombination enthält. Das untere Feld arbeitet andersherum: einen Wert aus einer Antwort, einer CDN-Einstellung oder einem Log einfügen, auf Header prüfen klicken und dieselbe Übersicht für diesen Text lesen. Beide Felder laufen in diesem Browser, und die Seite funktioniert auch offline weiter.
Cache-Control ist das HTTP-Response-Feld, das Caches sagt, wie lange eine Antwort wiederverwendet werden darf und was vorher geprüft werden muss: max-age und s-maxage setzen die Frist für Browser und gemeinsame Caches, no-store verbietet das Speichern, no-cache erlaubt das Speichern, verlangt aber eine Validierung, und immutable, stale-while-revalidate sowie stale-if-error verfeinern das. Dieses Werkzeug liest den Header-Text nach RFC 9111 und zeigt, was ein Cache daraus machen würde. Es ruft nie eine URL auf und kann deshalb nicht sagen, was Ihr Server, Ihr CDN oder der Browser-Cache im Betrieb tatsächlich tun.
public und private widersprechen sich: public markiert die Antwort als speicherbar für gemeinsame Caches, private verbietet genau diesen Caches das Speichern, eine der beiden Angaben muss also weg. no-store ist die stärkste Direktive — nichts darf gespeichert werden —, wodurch max-age, s-maxage und die Fenster für veraltete Inhalte im selben Header nutzlos werden; die Übersicht sagt das, statt eine Frist anzuzeigen, die nie greift. s-maxage lesen nur gemeinsame Caches, und private schließt sie aus, also bleibt s-maxage neben private wirkungslos.
immutable verspricht, dass sich die Ressource während ihrer Frische nicht ändert (RFC 8246); ohne max-age oder s-maxage gibt es kein Frischefenster, das dieses Versprechen abdeckt. must-understand gehört neben no-store, und ein Cache, der die Cache-Anforderungen des Statuscodes versteht, ignoriert den no-store-Teil (RFC 9111, Abschnitt 5.2.2.3). Auch eine fehlende Frist wird gemeldet: Ohne max-age, s-maxage oder no-cache kann ein Cache auf eine Heuristik ausweichen — üblich ist ein Zehntel der Zeit seit Last-Modified — und die Antwort ohne Rückfrage beim Ursprung wiederverwenden.
max-age, s-maxage, stale-while-revalidate und stale-if-error nehmen Delta-Sekunden, die RFC 9111 als eine oder mehr Ziffern definiert (Abschnitt 1.2.2): 0 ist gültig und bedeutet sofort veraltet, ein Dezimalpunkt gehört nicht zur Grammatik. Ein Wert in Anführungszeichen wie max-age="5" wird gemeldet, weil ein Sender die Tokenform verwenden muss (Abschnitt 5.2.2.1). Auch Werte über 2147483647 Sekunden werden markiert: Ein Cache, der die Zahl nicht darstellen kann, muss sie als 2147483648 Sekunden lesen — über 68 Jahre, was praktisch „nie veraltet“ bedeutet.
Die zweite Argumentform in diesem Feld ist die in Anführungszeichen gesetzte Feldnamenliste von no-cache und private, etwa no-cache="Set-Cookie". Kommas innerhalb dieser Anführungszeichen gehören zur Liste, deshalb trennt der Parser das Feld an Kommas außerhalb von Anführungszeichen und zählt einen solchen Wert als eine Direktive. Direktiven, die ein Cache nicht kennt, ignoriert er (Abschnitt 5.2.3) — genau deshalb ist ein Tippfehler wie maz-age=60 eine Meldung wert: Die Antwort würde weiterhin ausgeliefert, und die Regel würde schlicht nicht existieren.
Die Seite sendet nie eine Anfrage; sie liest nur Header-Text. Ob ein CDN, ein Reverse-Proxy oder ein Browser das Feld beachtet, hängt von der Konfiguration dieses Systems und vom Statuscode der Antwort ab, und ein Cache darf eine Antwort ganz ohne Direktiven speichern, wenn er sie als heuristisch cachebar einstuft. Prüfen Sie die Richtlinie an der echten Antwort — curl -I, die Cache-Header Ihres CDN oder das Netzwerk-Panel des Browsers —, bevor Sie sich darauf verlassen.
Zwei Nachbarfelder bleiben bewusst außen vor: Expires nennt ein absolutes Datum statt einer Frist, und Pragma ist ein HTTP/1.0-Request-Feld, das RFC 9111 für veraltet erklärt (Abschnitt 5.4). Deshalb wird eine Zeile, die mit einem anderen Feldnamen beginnt, abgelehnt statt als Cache-Control umetikettiert. Und weil die Prüfung textuell ist, kann ein einwandfreier Header trotzdem falsch zum Inhalt sein: no-store auf einem statischen Asset oder ein Jahr max-age auf einer Seite, die sich stündlich ändert, sind Entscheidungen, die kein Header-Prüfer abnehmen kann.