Zusammenfassung
- HTTP-Frische entsteht aus dem Vergleich von aktuellem Alter und geltender Frischefrist; Age enthält diese Entscheidung nicht vollständig.
- Ein belastbarer Nachweis verbindet Zeiten, Direktiven, Validierung, Berechtigung für veraltete Antworten und den Fingerabdruck der ausgelieferten Repräsentation.
Stellen wir uns vor, ein Betriebsdashboard liest Age: 20 aus einer gecachten Konfiguration und zeigt Grün. Der Wert wirkt klein. Die Antwort trägt jedoch max-age=10, und der Cache liefert sie während eines Origin-Ausfalls unter einer Erlaubnis für veraltete Antworten aus. Der Header kann korrekt und die Schlussfolgerung falsch sein.
RFC 9111 trennt Alter und Frischefrist. Eine Antwort ist frisch, solange ihr Alter die geltende Frist nicht überschritten hat; danach ist sie veraltet. Der Test lautet freshness_lifetime > current_age. Age nennt weder die maßgebliche Frist noch allein die vollständige Berechnung des aktuellen Alters.
Die Frischefrist folgt einer Rangfolge. Für einen gemeinsamen Cache hat s-maxage Vorrang, danach max-age, anschließend die Differenz zwischen Expires und Date. Fehlt eine ausdrückliche Ablaufzeit, darf unter bestimmten Bedingungen eine heuristische Frist gelten. Die Norm schreibt keinen einheitlichen Algorithmus vor, sodass konforme Systeme unterschiedliche Fristen berechnen können.
Auch Age ist berechnet. Es schätzt die Sekunden seit Erzeugung oder erfolgreicher Validierung durch den Origin und kann den empfangenen Age-Wert, Antwortverzögerung, die Differenz zu Date sowie die Aufenthaltszeit im aktuellen Cache verbinden. Wird eine gespeicherte Antwort ohne Validierung verwendet, muss der Cache ihr berechnetes aktuelles Alter senden.
Zwanzig Sekunden sind daher bei sechzig Sekunden Lebensdauer frisch, bei zehn Sekunden veraltet. Eine veraltete Antwort darf bei Trennung oder ausdrücklicher Erlaubnis geliefert werden, sofern keine anwendbare Direktive wie no-cache oder must-revalidate dies verbietet. Protokollkonformität ist nicht gleichbedeutend mit der fachlichen Gültigkeit eines Preises, Rechts oder Konfigurationsstands.
Gefordert ist ein Frischeentscheidungsbeleg. Er ist eine redaktionelle Synthese von Nachweisen und kein vom IETF oder in RFC 9111 definiertes Protokollelement. Er verbindet Cache-Identität und Konfiguration, Anfrageziel, gespeicherte Antwort und ausgelieferten Digest; Date, empfangenes und gesendetes Age, Anfrage-, Antwort- und Aufenthaltszeit; Quelle der Frischefrist, wirksame Direktiven, Validierungsergebnis, Erlaubnis zur veralteten Lieferung und Endentscheidung.
Quellen
- https://www.rfc-editor.org/rfc/rfc9111.html#section-4.2
- https://www.rfc-editor.org/rfc/rfc9111.html#section-4.2.1
- https://www.rfc-editor.org/rfc/rfc9111.html#section-4.2.2
- https://www.rfc-editor.org/rfc/rfc9111.html#section-4.2.3
- https://www.rfc-editor.org/rfc/rfc9111.html#section-4.2.4
- https://www.rfc-editor.org/rfc/rfc9111.html#section-5.1
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

