Zusammenfassung

  • RFC 5861 vom Mai 2010 erschien als unabhängiges informatives Dokument und beschrieb zwei getrennte Regeln: stale-while-revalidate für alte Antworten während der Prüfung, stale-if-error für alte Antworten bei einem Serverfehler.
  • Die Beispiele setzen genaue Zeiten: max-age=600, stale-while-revalidate=30 heißt zehn Minuten frisch und bis zu 30 Sekunden veraltet; max-age=600, stale-if-error=1200 kann bei Alter 900 Sekunden einen 500er durch ein gespeichertes 200 mit Age: 900 ersetzen.
  • RFC 9111 vom Juni 2022 behielt die ausdrückliche Erlaubnis als Schranke für alte Antworten bei und erklärte das frühere Feld Warning für obsolet.

Die alte Seite ist schneller als die Rückfrage

Ein Cache speichert eine Antwort, damit nicht jeder Leser erneut den Ursprungsserver beansprucht. Innerhalb der Frischezeit ist die Wiederverwendung einfach. Danach kostet die Prüfung auf Änderungen einen Netzweg und Serverarbeit, selbst wenn der Inhalt gleich geblieben ist. RFC 5861 gab dem Ursprung eine Möglichkeit, für eine kurze Zeit zuerst die Kopie und danach das Ergebnis der Prüfung zu liefern.

Der Wert Cache-Control: max-age=600, stale-while-revalidate=30 lässt die Antwort 600 Sekunden frisch sein. In den nächsten 30 Sekunden darf der Cache die inzwischen veraltete Kopie sofort senden und im Hintergrund beim Ursprung nachfragen. Der Leser wartet nicht auf diese Runde. Das Nachfragen bestimmt, was die folgenden Leser bekommen. Der Herausgeber hat die kurze Verzögerung seiner Änderungen selbst zugelassen.

Auch ohne Besucher, der die Prüfung auslöst, läuft das Zeitfenster ab. Bleibt die Validierung ohne Ergebnis, wartet die nächste Anfrage nach den 30 Sekunden auf normale Behandlung. Eine selten besuchte Seite kann die Abkürzung verpassen. Verkehrsmenge und Zeitfenster entscheiden gemeinsam, ob der Cache Wartezeit wirklich verbirgt. Die zusätzliche Dauer ist eine begrenzte Betriebserlaubnis, kein neues Haltbarkeitsdatum für die Information.

Ein alter Erfolg deckt den aktuellen Fehler

stale-if-error beginnt mit einem anderen Ereignis. Der Cache versucht eine aktuelle Antwort zu erhalten und stößt auf eine Lage, die einen 500, 502, 503 oder 504 ergäbe. Innerhalb der veröffentlichten Altersgrenze darf er den gespeicherten alten Erfolg senden. Der Nutzer sieht den Inhalt, den der Ursprung früher liefern konnte, statt des Fehlers dieser neuen Anfrage.

Das Beispiel im RFC trägt max-age=600, stale-if-error=1200. Bei einem Alter von 900 Sekunden ergibt ein Validierungsversuch einen 500. Der Cache kann daraufhin den gespeicherten Körper mit 200 OK und Age: 900 ausliefern. Der Status 200 beschreibt das gelieferte Dokument; Age beziffert die vergangene Zeit seit Erzeugung oder erfolgreicher Validierung am Ursprung. Der aktuelle Fehler wurde zeitlich begrenzt überdeckt.

Die 1.200 Sekunden beginnen nach der 600-Sekunden-Frischezeit. Überschreitet das Gesamtalter im Beispiel 1.800 Sekunden, gelangt der Fehler zum Client. Ein Nachschlagewerk kann vielleicht zwanzig Minuten alt sein, wenn der Server kurz ausfällt. Eine Berechtigungs- oder Zahlungsantwort kann durch dieselbe Verzögerung falsche Entscheidungen auslösen. Der Wert gehört zur Bedeutung der jeweiligen Ressource, nicht zur kosmetischen Pflege einer Verfügbarkeitsstatistik.

Langsame Prüfung und fehlgeschlagene Prüfung brauchen deshalb verschiedene Grenzen. stale-while-revalidate verdeckt Latenz, während eine Kontrolle läuft. stale-if-error überbrückt einen Fehler. Der Ursprung kann beide Zeitfenster getrennt wählen; der Cache entscheidet innerhalb der erlaubten Fälle, ob er die Kopie einsetzt. Eine pauschale Einstellung „Altes ist gut genug“ würde diese Unterschiede verbergen.

Das Warnschild wurde abgeschafft

Der Text von 2010 erwartete nach den damaligen HTTP-Regeln ein Age größer als null und ein Feld Warning, wenn eine alte Antwort gesendet wurde. RFC 9111 strich Warning 2022: Es wurde selten erzeugt oder Nutzern gezeigt. Age blieb als Schätzung der Zeit seit dem Ursprung oder dessen letzter erfolgreicher Validierung. Wer heute nur auf die Warnung wartet, übersieht möglicherweise die ältere Kopie hinter einem normalen 200.

Das neuere Caching-RFC hält weitere Grenzen fest. no-cache, must-revalidate und ähnliche ausdrückliche Verbote sperren die Verwendung alter Antworten. Sonst braucht der Cache Trennung vom Ursprung, eine ausdrückliche Erlaubnis von Client oder Ursprung, oder eine Vereinbarung außerhalb des Protokolls. Die Erweiterungen aus RFC 5861 sind Beispiele für diese Erlaubnis. Der Cache hat Entscheidungsraum, aber keine eigene Hoheit über die Aktualität sämtlicher gespeicherter Ressourcen.

RFC 5861 war eine informative unabhängige Veröffentlichung; RFC 9111 ist ein Standards-Track-Dokument und nennt die beiden Regeln im Rahmen zulässiger Ausnahmen. Für tatsächliche Verbreitung fehlen datierte Antwortköpfe, Cache-Konfigurationen und Mitschnitte während Störungen. Die Textgeschichte zeigt schon die Arbeitsteilung: Der Ursprung setzt eine Altersgrenze, der Cache kauft damit Geschwindigkeit oder Kontinuität, und der Leser erhält eine möglicherweise überholte Welt.