Zusammenfassung

  • Age schätzt die Sekunden seit der Erzeugung oder erfolgreichen Validierung einer Antwort beim Ursprungsserver. Es ist nicht das Alter der URL, des Dokuments oder der dargestellten Bytes.
  • Ein Cache verbindet das empfangene Age mit Date, lokalen Anfrage- und Antwortzeiten, Verzögerung und Aufenthaltsdauer; bei Wiederverwendung ohne Validierung ersetzt er den Wert durch ein einziges current_age.
  • Frische ist ein eigener Vergleich zwischen aktuellem Alter und einer Lebensdauer aus Cache-Direktiven, Expires oder einer zulässigen Heuristik. Die Zahl beweist weder Validierung noch Wiederverwendungsrecht.

Zwei Minuten konnten auf jahrealten Inhalt zeigen

Ein Handbuch wurde vor vier Jahren veröffentlicht und seitdem nicht verändert. Heute bestätigt der Ursprung gegenüber einem Cache, dass dessen Kopie weiterhin gültig ist. Zwei Minuten später ist Age: 120 für diese Antwort korrekt, obwohl das Handbuch viel älter ist.

Im Alltag gehört Alter zu einer Sache. HTTP ordnet es einer Antwort zu. Eine Ressource kann älter als der Server sein, dieselben Bytes können wiederholt validiert werden, und ein lokaler Cache-Eintrag kann ersetzt oder aktualisiert worden sein. Diese Geschichten passen nicht in das Feld und sollten dort auch nicht stehen.

Die praktische Frage war enger: Darf ein Cache eine frühere Antwort für eine neue Anfrage nutzen, ohne den Ursprung zu kontaktieren? Dafür musste die schon bei anderen Caches verstrichene Zeit weitergegeben werden. Ein Neubeginn bei null verjüngt die Antwort an jeder Grenze; allein Date führt bei abweichenden Uhren zu falschen Differenzen.

HTTP/1.0 hatte keine gemeinsame Antwortuhr

HTTP/1.0 beschrieb 1996 Caching, Datumswerte und Ablauf. Im definierten Satz der Response-Header fehlte jedoch Age, ebenso ein interoperabler Algorithmus für die zuvor angesammelte Zeit. Ein Cache sah lokale Empfangszeit, Date und Expires, aber keinen standardisierten Stand des vorherigen Speichers.

Hält Cache A eine Antwort achtzig Sekunden und gibt sie an B weiter, verliert B dieses Intervall, wenn er neu zählt. Subtrahiert B nur die Ursprungszeit von seiner Uhr, kann Taktabweichung ein negatives oder überhöhtes Alter erzeugen.

HTTP/1.1 führte 1997 Age ein. Der sendende Cache übergab seine Schätzung; der nächste korrigierte und verlängerte sie. Schon die frühe Regel unterschied Revalidierung von Inhaltserzeugung: Nach erfolgreicher Bestätigung beruhte das Alter auf der Validierung und nicht zwingend auf der ursprünglichen Antwort. Das Feld war kein Publikationsdatum.

Zwei unvollkommene Perspektiven wurden kombiniert

Beim Empfang kann ein Cache zunächst das scheinbare Alter aus Date berechnen:

apparent_age = max(0, response_time - date_value)

Die Untergrenze null verhindert negatives Alter, wenn die Ursprungsuhr vorgeht. Trotzdem vergleicht diese Sicht zwei verschiedene Uhren.

Die zweite Sicht übernimmt den eingehenden Wert und ergänzt die lokale Anfrageverzögerung:

response_delay = response_time - request_time

corrected_age_value = age_value + response_delay

Sie kommt ohne direkte Subtraktion entfernter Uhren aus, setzt aber voraus, dass frühere HTTP/1.1-Caches Age korrekt einfügten. Ein alter Zwischenknoten kann Zeit unterschlagen.

Wo diese Kompatibilität zählt, verwendet die konservative Rechnung:

corrected_initial_age = max(apparent_age, corrected_age_value)

Die aktuelle Spezifikation erlaubt den korrigierten Wert direkt, wenn sehr alte Caches keine Rolle spielen. Es gibt keine souveräne Netzuhr. Lokaler Code verbindet sichtbare Hinweise nach einer reproduzierbaren Regel.

Aufenthaltszeit entstand nur am Aufenthaltsort

Nach dem Empfang liegt die Antwort im Speicher. Erst die nächste Anfrage zeigt, wie lange. Der lokale Cache berechnet:

resident_time = now - response_time

current_age = corrected_initial_age + resident_time

Verwendet er die gespeicherte Antwort ohne Validierung, erzeugt er Age neu und ersetzt den vorherigen Wert. Er hängt weder eine zweite Zahl noch eine Cache-Liste an. Der folgende Cache erbt die Summe und ergänzt eigene Verzögerung und Aufenthaltszeit.

Die Zahl bewahrt Dauer, nicht Topologie. Zwei lange Aufenthalte können dasselbe Ergebnis liefern wie zehn kurze. Namen, Hop-Zahl, Reihenfolge, Verwahrung oder Empfangsquittungen lassen sich daraus nicht ableiten. Age setzt eine Rechnung fort; es rekonstruiert keinen Herkunftspfad.

Diese Beschränkung reduziert den Koordinationsaufwand. Der Empfänger benötigt keine fremden Betriebsprotokolle. Für die spätere Ursachenklärung muss jeder Betreiber allerdings mehr als die übertragene Summe behalten.

Frische kam aus einem anderen Konto

Age: 120 sagt nicht, dass noch 120 Sekunden verbleiben. Das Alter beschreibt vergangene Zeit. Die freshness lifetime beschreibt, wie lange eine Wiederverwendung ohne Validierung zulässig ist. Die Entscheidung lautet:

response_is_fresh = (freshness_lifetime > current_age)

Die Lebensdauer kann aus s-maxage, max-age, der Differenz zwischen Expires und Date oder einer erlaubten Heuristik stammen. 120 Sekunden sind gegenüber 300 Sekunden frisch und gegenüber 60 Sekunden stale.

Stale bedeutet nicht falsch, gefährlich oder inhaltlich veraltet. Es bedeutet, dass der normale Frischevergleich nicht mehr erfüllt ist. Validierung kann die Antwort wieder nutzbar machen. Direktiven oder ein getrennter Betrieb können stale Bedienung zulassen. Umgekehrt kann eine junge Antwort wegen Speicherverbot oder falscher Variante ungeeignet sein.

Auswahl, Alter, Frischelebensdauer und Wiederverwendung sind getrennte Entscheidungen. Wer sie in ein Feld legt, macht aus einem Messwert eine Autorität.

Validierung änderte den Bezugspunkt, nicht die Vergangenheit

Ein Cache kann nach einem Tag eine bedingte Anfrage senden. Bestätigt der Ursprung die Darstellung, bleiben dieselben Bytes erhalten, während die Altersbasis auf der erfolgreichen Validierung beruht. Ein kleinerer Wert beweist daher keine Inhaltsänderung; ein großer Wert beweist keinen Ausfall des Ursprungs.

Age enthält weder den verglichenen ETag noch den Validierungsstatus oder aktualisierte Metadaten. Die Transaktion braucht eine eigene Spur. Das vorhandene Feld erlaubt nur die Aussage, dass die Antwort nicht aus erster Hand stammt: Ein Cache hat sie aus gespeichertem Zustand erzeugt. Ob dieser Cache während der aktuellen Anfrage beim Ursprung validierte oder sich auf eine frühere Validierung stützte, verrät das Feld allein nicht. Ein fehlendes Feld beweist keinen Ursprungskontakt.

Sättigung war kein 68-Jahre-Protokoll

Der Wert ist eine nichtnegative ganze Sekundenzahl. Ungültige Angaben sollen ignoriert werden. Übersteigt ein Wert den darstellbaren Bereich oder läuft eine Rechnung über, gilt historisch 2147483648 oder die größte bequem darstellbare positive Zahl.

Dieses praktische Unendlich verhindert, dass ein Überlauf als kleine oder negative Zahl erscheint. Es ist keine genaue Beobachtung einer 2.147.483.648 Sekunden langen Speicherung.

Erklärbarkeit braucht alle Rechenterme

Ein Audit benötigt Cache-Key und Variante, empfangene Date-, Age-, Direktiven- und Validatorwerte, lokale Anfrage-, Antwort- und Entscheidungszeit, alle Zwischenergebnisse und die Quelle der Frischelebensdauer. Ebenso wichtig sind Validierungsergebnis und Pfad: frisch, validiert, zulässig stale oder Fehler.

Nur die Endzahl zu speichern, vermischt geerbten Aufenthalt, Übertragung, lokale Speicherung und Uhrkorrektur. HTTP ersetzte diese Lücke nicht durch ein zentrales Zeitamt. Ursprung und Caches behalten getrennte Aufgaben; die gemeinsame Zahl koordiniert nur, was jeder nächste Knoten lokal fortsetzen kann.

Quellen