HTTP-Cache-Ablauf-Rechner
Geben Sie die Werte von Cache-Control, Expires, Date und Age einer Antwort, den Zeitpunkt des Empfangs und den Prüfzeitpunkt ein. Der Rechner liefert die Frischedauer, das aktuelle Alter und ob die Antwort noch frisch ist.
Was dieser Rechner tut
Er deckt einen Teil von RFC 9111 ab, der HTTP-Caching-Norm: die Frischeberechnung. Das ist der Teil, der entscheidet, ob eine gespeicherte Antwort ohne Rückfrage beim Ursprungsserver wiederverwendet werden darf. Validierung (ETag, If-Modified-Since, 304), Vary und Cache-Control auf der Anfrageseite werden nicht behandelt.
Frische ist kein Aktualisieren und kein Löschen
Dass eine Antwort veraltet ist, bedeutet nur, dass ein Cache sie nicht ohne vorherige Prüfung wiederverwenden darf. Es bedeutet nicht, dass sich die Browseranzeige von selbst aktualisiert, und nicht, dass die Datei auf dem Ursprungsserver geändert oder gelöscht wird. Ebenso heißt eine frische Antwort nicht, dass sich die Datei auf dem Server nicht geändert hat. Der Expires-Header, so die Norm, „does not imply that the original resource will change or cease to exist at, before, or after that time“. Dieser Rechner arbeitet nur die Zeitarithmetik der zwischengespeicherten Kopie durch.
Frischedauer und aktuelles Alter
- Frischedauer: die Zeitspanne, die die Antwort „frisch“ bleiben kann. Sie wird von der Antwort selbst bestimmt (Cache-Control oder Expires) und ändert sich mit der Zeit nicht.
- Aktuelles Alter: die Zeit, die vergangen ist, seit die Antwort erzeugt wurde. Es wächst mit der Zeit.
- Ist sie frisch? Die Antwort ist nur dann frisch, wenn die Frischedauer größer ist als das aktuelle Alter (bei Gleichheit ist sie veraltet).
- Verbleibende Frische = Frischedauer − aktuelles Alter.
Welcher Wert die Frischedauer bestimmt
Nach Abschnitt 4.2.1 von RFC 9111 wird der erste Treffer verwendet:
| Reihenfolge | Gemeinsamer Cache (CDN, Proxy) | Privater Cache (Browser) |
|---|---|---|
| 1 | s-maxage | (s-maxage wird nicht verwendet) |
| 2 | max-age | max-age |
| 3 | Expires − Date | Expires − Date |
| 4 | Ist keiner vorhanden, gibt es kein explizites Ablaufdatum | Gleich |
- Ist max-age vorhanden, wird Expires ignoriert. In einem gemeinsamen Cache werden bei vorhandenem s-maxage max-age und Expires ignoriert (Abschnitt 5.3).
- Kommt dieselbe Direktive mehrmals vor, wird die erste verwendet (einer der von der Norm erlaubten Ansätze).
- Ein max-age oder s-maxage, das keine ganze Zahl ist oder in Anführungszeichen steht (die Norm sagt, ein Sender darf die Form mit Anführungszeichen nicht erzeugen), wird als ungültig behandelt, und die Antwort gilt als veraltet (Frischedauer 0). Ein Wert über 2.147.483.648 wird als 2.147.483.648 behandelt (Abschnitt 1.2.2).
- Ist Expires
0oder ein Datum, das es nicht gibt, gilt die Antwort als bereits abgelaufen (Abschnitt 5.3). - Gibt es kein explizites Ablaufdatum, wird keine heuristische Frische (zum Beispiel eine Schätzung aus Last-Modified) berechnet. Die Norm überlässt die heuristische Dauer der Implementierung.
Wie das aktuelle Alter berechnet wird
Die Formeln stammen aus Abschnitt 4.2.3 von RFC 9111:
- Scheinbares Alter = max(0, Empfangszeit − Date)
- Alter beim Empfang = max(scheinbares Alter, Age-Header + Antwortverzögerung)
- Aktuelles Alter = Alter beim Empfang + Zeit seit dem Empfang
Dieser Rechner fragt nicht nach dem Zeitpunkt, zu dem die Anfrage gesendet wurde, daher setzt er die Antwortverzögerung (die Zeit vom Senden der Anfrage bis zum Empfang der Antwort) als 0 an. Bei einer Verbindung mit großer Verzögerung kann das berechnete Alter kleiner sein als das tatsächliche. Die Norm erlaubt auch, allein den Age-Header plus die Verzögerung zu verwenden.
Regeln für die Eingabe
- Geben Sie Daten als IMF-fixdate (zum Beispiel
Sun, 06 Nov 1994 08:49:37 GMT) oder als UTC-Zeit wie2026-10-21 07:28:00ein. Alles ist in UTC (GMT); Zeitzonen werden nicht behandelt. Das Jahr muss von 1900 bis 2100 reichen und die Sekunden von 0 bis 59 (eine Schaltsekunde, 60, wird nicht akzeptiert). Der Wochentagsname wird nicht gegen das Datum geprüft. - Die Formate RFC 850 und asctime sind Formate, die HTTP-Empfänger akzeptieren sollen, aber dieser Rechner unterstützt sie nicht. (Das heißt nicht, dass sie in HTTP ungültig sind. Wandeln Sie den Wert in ein IMF-fixdate um.)
- Ist Date leer, wird die Zeit, die Sie bei „Zeitpunkt des Empfangs der Antwort“ eingeben, anstelle von Date verwendet. RFC 9110 sagt, dass ein Empfänger, der eine Antwort ohne Date erhält, den Empfangszeitpunkt festhält und als Date hinzufügt. Ist auch diese Zeit leer, lassen sich die Berechnungen, die Date brauchen (Expires − Date und das scheinbare Alter), nicht ausführen. Die aktuelle Browserzeit wird nie automatisch verwendet; sie wird nur eingetragen, wenn Sie auf die Schaltfläche „Aktuelle Zeit“ drücken, und zwar in das Feld „Prüfzeitpunkt“.
- Der zu prüfende Zeitpunkt darf nicht vor dem Empfangszeitpunkt der Antwort liegen.
Weitere Cache-Control-Direktiven
Sie werden in der Berechnung nicht verwendet, aber als Hinweise zur Wiederverwendung angezeigt.
- no-store: darf nicht gespeichert werden. private: ein gemeinsamer Cache darf sie nicht speichern (ein Browser darf es).
- no-cache (ohne Argumente): Selbst wenn sie frisch ist, kann sie ohne Validierung nicht wiederverwendet werden.
- must-revalidate: Ist sie veraltet, darf sie nicht ohne Validierung verwendet werden. proxy-revalidate: dasselbe, gilt aber nicht für einen privaten Cache.
- public: erlaubt das Speichern ausdrücklich.
- immutable (RFC 8246) sowie stale-while-revalidate und stale-if-error (RFC 5861) liegen außerhalb von RFC 9111. Sie werden erkannt, aber in der Berechnung nicht verwendet.
Beispiele
| Eingabe | Ergebnis |
|---|---|
| max-age=3600, kein Age, 1.800 s nach dem Empfang | Frischedauer 3.600 s, aktuelles Alter 1.800 s, 1.800 s verbleibend (frisch) |
| Dasselbe, genau bei 3.600 s | Aktuelles Alter 3.600 s. Es entspricht der Frischedauer, daher ist sie veraltet |
| max-age=3600, Age=600, gerade empfangen | Aktuelles Alter 600 s, 3.000 s verbleibend |
| Gemeinsamer Cache mit s-maxage=60, max-age=3600 | Frischedauer 60 s (max-age wird ignoriert) |
Gut zu wissen
- Dies ist eine Berechnung auf Grundlage der Norm. Echte Browser und CDNs verhalten sich nicht immer genau so, wie die Norm es beschreibt. Aktionen wie ein erzwungenes Neuladen und CDN-spezifische Einstellungen können andere Ergebnisse liefern. Das Verhalten eines bestimmten Produkts ist nicht garantiert.
- Heuristische Frische, Validierung, Vary, Anfragedirektiven und das Aufsummieren mehrerer Caches werden nicht behandelt.
Quellen und Prüfungen
Folgendes wurde am 1. November 2026 am vollständigen Text der Normen geprüft:
- RFC 9111, „HTTP Caching“: https://www.rfc-editor.org/rfc/rfc9111 (Abschnitte 1.2.2, 4.2.1, 4.2.3, 5.1, 5.2.2 und 5.3, einschließlich des Frischetests
freshness_lifetime > current_age) - RFC 9110, „HTTP Semantics“: https://www.rfc-editor.org/rfc/rfc9110 (Abschnitte 5.6.7 und 6.6.1)
Dieser Rechner folgt diesen Abschnitten nur für die Frische. Dass diese Berechnung stimmt, ist keine Behauptung, dass ein Produkt oder ein Server der Norm entspricht.
Häufige Fragen
Was geschieht, wenn sowohl max-age als auch Expires vorhanden sind?
max-age hat Vorrang, und Expires wird ignoriert (RFC 9111, Abschnitt 5.3).
Gilt s-maxage für einen Browser?
s-maxage ist eine Direktive für gemeinsame Caches. Ein privater Cache (ein Browser) verwendet sie nicht.
Was ist der Age-Header?
Er ist die Zahl der Sekunden seit der Erzeugung der Antwort oder ihrer letzten Prüfung am Ursprung, von einem Cache unterwegs eingetragen. Dieser Rechner verwendet ihn, um das aktuelle Alter zu bestimmen.
Verschwindet eine veraltete Antwort oder aktualisiert sie sich von selbst?
Nein. Veraltet heißt nur, dass ein Cache vor der Wiederverwendung prüfen muss. Es aktualisiert weder die Anzeige noch ändert es etwas auf dem Ursprungsserver.
Wie kann ich eine Zeit prüfen?
Der Unix-Zeitstempel-Umrechner und der Cron-Ausdruck-Rechner können helfen.