Zusammenfassung

  • Nach RFC 9211 ist Cache-Status eine Structured-Fields-Liste, in der jedes Mitglied für genau einen Cache steht. Die Reihenfolge reicht vom ursprungsnahen zum nutzernahen Cache und bildet keinen gemeinsamen Beschluss.
  • Die Parameter sind eng begrenzt: hit garantiert keine Frische, ttl darf negativ sein, und stored oder collapsed sind nur zusammen mit fwd im selben Mitglied sinnvoll.
  • Belastbare Auswertung hält Reihenfolge, Rohwert, Zeitpunkt und Beobachtungspunkt fest. Sie trennt die angegebene Kennung von einer verifizierten Identität und gibt sensible Details nur zielgruppengerecht frei.

Drei Stationen ergeben nicht automatisch eine Antwort

Eine Anfrage durchläuft beispielsweise einen regionalen Edge-Cache, ein Unternehmens-Gateway und den Browser-Cache. Der Edge kann wegen einer Validierung weiterleiten. Das Gateway kann die zurückkommende Antwort speichern. Der Browser kann später lokal antworten. Alle drei Vorgänge passen zusammen.

Cache-Status gibt jedem berichtenden Cache ein eigenes Listenelement. Wer ein Element ergänzt, soll bereits vorhandene Elemente bewahren. RFC 9211 ordnet sie vom Cache nahe am Ursprung bis zum Cache nahe am User Agent. Ein hit am Ende widerlegt damit kein fwd am Anfang.

Diese Ordnung ist weder Abstimmung noch Gesamtberechnung. Sie verspricht auch keine Vollständigkeit. Ein Cache darf das Feld immer, nur bei passender Konfiguration oder nach einer Debug-Anfrage ausgeben. Einzelne Parameter sind optional. Ein stiller Vermittler bleibt möglich.

Eine saubere Aussage lautet deshalb: An diesem Messpunkt kam für diese Antwort diese Folge von Angaben an. Die stärkere Behauptung, damit seien alle beteiligten Caches bewiesen, wäre unbelegt. HTTP-Felder können unterwegs zudem verändert werden.

Eine Kennung ist noch keine beglaubigte Identität

Jedes Element beginnt mit einer Kennung als Structured-Fields-String oder -Token. Möglich sind Produkt- oder Dienstname, Hostname, IP-Adresse oder eine erzeugte Zeichenfolge. Betreiber können dadurch auf unnötig genaue Topologieangaben verzichten.

Die Kennung wird jedoch vom meldenden Cache selbst gewählt. Syntaktische Gültigkeit authentifiziert den Absender nicht. In einer verwalteten Umgebung können geschützte Wege, Inventar, Deployment-Nachweise und interne Sammler eine starke Zuordnung liefern. Außerhalb dieser Umgebung bleibt derselbe Text zunächst eine Selbstauskunft.

Ein Prüfdatensatz sollte vier Dinge auseinanderhalten: die angegebene Kennung, den Beobachtungspunkt, den externen Nachweis für die Bindung an einen erwarteten Absender und die analytische Vertrauensstufe. Ein einzelnes Feld namens trusted verschluckt die Begründung.

RFC 9421 beschreibt HTTP Message Signatures. Eine gesonderte Integritätspolitik kann ausgewählte Nachrichtenbestandteile mit verwalteten Schlüsseln schützen. Daraus folgt nicht, dass gewöhnliche Cache-Status-Elemente signiert sind. Auch eine Signatur benötigt Aussagen über Unterzeichner, abgedeckte Bestandteile und erlaubte Transformationen.

hit ist kein Frischesiegel

hit=true besagt, dass dieser Cache die Anfrage nicht weitergeleitet und die Antwort aus seinem Cache bezogen hat. Der Begriff garantiert nicht, dass die Antwort frisch war. Darf nach den einschlägigen Regeln eine veraltete Antwort ohne Weiterleitung ausgeliefert werden, kann das weiterhin ein hit sein.

Umgekehrt reicht ein gespeichertes Objekt nicht für hit. Muss die Anfrage etwa zur Validierung weitergeleitet werden, gehört die Bearbeitung zum fwd-Zweig. hit und fwd schließen einander aus, weil sie die Weiterleitungsentscheidung für genau diese Anfrage beschreiben.

Damit darf dieselbe Kennzahl nicht mehrere Ziele vertreten. Origin-Last, Frische, Trennung personalisierter Inhalte und Latenz sind verschiedene Fragen. hit kann zeigen, ob eine Ebene den Ursprung vermieden hat; es ersetzt weder Cache-Regeln noch Anfragekontext, Schlüssel und Validierungsbeleg.

Auch die Aggregation braucht den Absender. Wer hit über alle Listenelemente summiert, kann dieselbe Antwort mehrfach zählen und verdeckt, welche Ebene entschieden hat.

fwd bringt seine eigenen Voraussetzungen mit

fwd nennt den spezifischsten bekannten Grund für die Weiterleitung. RFC 9211 stellt gemeinsame Tokens für Umgehung, Methode, URI-Abweichung, Miss, Veraltung und Validierung bereit. Das schafft Vergleichbarkeit, ohne interne Zustandsmaschinen zu vereinheitlichen.

fwd-status ist nur zusammen mit fwd definiert; fehlt der Wert, gilt der an den Client gesendete Antwortstatus als Vorgabe. stored sagt, ob die weitergeleitete Antwort gespeichert wurde. collapsed unterscheidet erfolgreiche Mitnutzung einer bereits laufenden Anfrage von einer neu ausgelösten Anfrage. stored und collapsed sind keine allgemeinen Eigenschaften eines hit-Elements.

Flache Datenschemata machen aus fehlenden Parametern gern false. Damit werden „nicht anwendbar“, „nicht offengelegt“ und „nicht beobachtet“ ununterscheidbar. Das Datenmodell muss Parametersatz und semantische Voraussetzungen am jeweiligen Listenelement halten.

Der Rohwert gehört daneben. Cache-Status folgt der formalen Structured-Fields-Grammatik und darf nicht mit einer beiläufigen Kommatrennung verarbeitet werden. RFC 9211 bezieht sich auf RFC 8941; RFC 9651 löste die allgemeine Structured-Fields-Spezifikation später ab. Diese Entwicklung ändert den eingefrorenen Vertrag von RFC 9211 nicht stillschweigend.

ttl ist eine lokale Rechnung

ttl gibt die verbleibende Frischelebensdauer an, wie sie der meldende Cache nahe am Zeitpunkt der Felderzeugung berechnet. HTTP-Altersregeln, Heuristiken und lokale Konfiguration können einfließen. Bei einer veralteten Antwort ist ein negativer Wert zulässig.

Mehrere ttl-Werte in einer Kette sind daher keine Messpunkte derselben Uhr. Sie können auf anders gespeicherte Objekte, andere Richtlinien und andere Berechnungszeitpunkte zurückgehen. Ihre Differenz ist keine Netzlatenz; ihr Minimum ist keine globale Lebensdauer.

Sinnvolle Fragen bleiben einem Element zugeordnet: Liefert dieser Cache oft ohne Weiterleitung aus, obwohl er negative ttl meldet? Ändert sich die Verteilung nach einer Heuristik-Anpassung? Warum validiert er bei scheinbar positiver lokaler ttl? Erst der Abgleich mit seiner Richtlinie trägt die Antwort.

Auch der Erfassungszeitpunkt ist Teil des Befunds. Cache-Status beschreibt die Verarbeitung einer konkreten Antwort, keine dauerhafte Eigenschaft einer URL. Die nächste Anfrage kann einen anderen Weg oder Zustand sehen.

key und detail brauchen abgestufte Sichtbarkeit

key kann eine implementierungsspezifische Darstellung des Cache-Schlüssels enthalten. detail trägt lokale Information; derselbe Wert kann bei zwei Caches etwas anderes bedeuten. Soll eine Bedeutung interoperabel werden, verweist RFC 9211 auf einen registrierten Parameter oder ein separates Feld.

Das IANA-Register für Cache-Status-Parameter verwendet Expert Review. Allgemeine Begriffe können gemeinsam definiert, anbieterspezifische Erweiterungen passend gekennzeichnet werden. Das Register koordiniert Semantik, genehmigt aber keine einzelne Offenlegung im Betrieb.

Der Sicherheitsabschnitt von RFC 9211 erklärt die Gefahr. Angaben können helfen, Komponenten zu sondieren, Nutzeraktivität abzuleiten, Timing-Angriffe vorzubereiten oder Bestandteile eines Cache-Poisoning-Angriffs zu erkennen. Eine bloße Verschleierung des Schlüssels genügt nicht. Auch Hostnamen und Routingdetails können die Angriffsfläche kartieren.

Eine öffentliche Antwort kann deshalb nur grobe Kennung und allgemeine Behandlungskategorie zeigen. Authentifizierte Diagnose darf mehr erhalten. Schlüsselbestandteile, Mandanten- und Topologiedaten bleiben in geschützten Protokollen. Parsergültigkeit ist keine Veröffentlichungserlaubnis.

Sechs Schritte für eine nachvollziehbare Lesart

Zuerst werden Feld, Zeitpunkt, Anfragekontext und Beobachtungspunkt unverändert gespeichert. Dann folgt die Auswertung als geordnete Structured-Fields-Liste. Jedes Element bleibt eine eigene Aussage; kein Parameter wandert in ein globales Objekt.

Danach gelten die Bedingungen: hit gegen fwd, die von fwd abhängigen Parameter, lokale ttl und lokale detail. Identitätsbindung und Vertrauen werden getrennt ergänzt. Abschließend entscheidet eine Offenlegungsstufe, welche Darstellung eine Grenze passieren darf.

Ein Bericht kann dann festhalten: „Das sich als regionaler Edge bezeichnende Element meldete miss und Speicherung; das nachfolgende meldete hit. Die erste Kennung ist an verwaltete Infrastruktur gebunden, die zweite nicht unabhängig authentifiziert.“ Das ist länger als „globaler Miss“, aber überprüfbar.

Quellen