Zusammenfassung

  • Ein Cache-Status-Eintrag beschreibt, wie der meldende Cache die zugehörige Anfrage und Antwort behandelt hat; hit und fwd besitzen eine definierte lokale Bedeutung.
  • Caches entscheiden selbst über die Ausgabe, Parameter sind optional und die Offenlegung kann eingeschränkt werden; eine kurze Liste beweist daher nicht, dass keine weiteren Caches oder Entscheidungen existierten.

Nehmen wir eine ausdrücklich hypothetische Störungsanalyse. Die Antwort enthält Cache-Status: edge; hit. Das Dashboard zeichnet einen einzigen grünen Kasten, erklärt den Lieferweg zur Kette mit nur einem Cache und vermerkt, dass kein vorgelagertes System beteiligt gewesen sei. Der Eintrag kann wahr sein: Der Edge-Cache beantwortete diese Anfrage aus seinem Speicher und leitete sie nicht weiter. Ein origin-näherer Cache könnte die gespeicherte Antwort jedoch bei einem früheren Austausch geliefert und sein eigenes Feld weggelassen haben. Die aktuelle Antwort beschreibt die Handlung des Edge-Caches, nicht die gesamte Entstehungsgeschichte des gespeicherten Objekts.

RFC 9211 gibt Cache-Status eine präzise, aber begrenzte Aufgabe. Jedes Listenelement steht für einen Cache, der die Anfrage behandelt und sich für eine Meldung entschieden hat. Bleiben mehrere Einträge erhalten, verlaufen sie vom origin-nächsten zum nutzernächsten Cache. Fügt ein Cache seinen Eintrag hinzu, sollte er vorhandene Werte bewahren. Damit eignet sich das Feld gut zur Fehlersuche in der sichtbaren Kette.

Vollständigkeit wird nicht zugesichert. Laut Spezifikation bestimmen Caches, wann das Hinzufügen angemessen ist. Eine Installation sendet das Feld vielleicht immer, eine andere nur nach Konfiguration oder wenn die Anfrage einen Diagnosemodus aktiviert. Sicherheitsregeln können Weglassen oder selektive Offenlegung verlangen, weil Cache-Zustand, Nutzeraktivität und Schlüsselaufbau Angriffe erleichtern können. Ein fehlender Eintrag bedeutet somit „hier nicht gemeldet“, nicht zwingend „hier war kein Cache“.

Auch die Parameter beschreiben lokale Tatsachen. hit bedeutet, dass der meldende Cache diese Anfrage nicht weiterleitete und die Antwort aus dem Cache bezog. fwd bedeutet, dass er sie in Richtung Origin weiterleitete; Gründe können uri-miss, vary-miss, stale oder request sein. Diese Aussagen sind betrieblich wertvoll und dürfen nicht zu grenzenlosen Ampelfarben verwässert werden.

Lokale Wahrheit ist jedoch keine vollständige Topologie. fwd-status nennt den Status der nächsten Serverstation. Diese kann ein weiterer Vermittler und nicht der Origin sein. Die Cache-Kennung kann Produktname, Hostname, Adresse oder eine erzeugte Zeichenfolge sein. Optionale Details sind installationsabhängig. Ohne Konfiguration und Beobachtungspunkt garantieren gleiche Namen keine gleiche Rolle, und unterschiedliche Namen beweisen keine unabhängigen Systeme.

Auch der Zeitbezug begrenzt die Aussage. Cache-Status beschreibt die entsprechende Anfrage und Antwort. Ein hit erzählt nicht, wann und über welche Kette die gespeicherte Antwort erworben wurde. Er beweist nicht, dass der Origin in der Geschichte des Objekts nie kontaktiert wurde. Ebenso erklärt eine Antwort nicht die Behandlung einer benachbarten Anfrage mit anderen Direktiven, Zugangsdaten, Vary-Werten oder Frischebedingungen. RFC 9111 behandelt diese Entscheidungen anfragebezogen.

Diese Trennung schützt die Störungszuordnung. Ein sichtbares fwd=stale; fwd-status=304 stützt die Aussage, dass der meldende Cache von seiner nächsten Station 304 erhielt. Allein beweist es weder, dass diese Station der Origin war, noch dass alle Caches meldeten oder anderswo dieselbe Entscheidung fiel. Ein knappes Feld kann einen kurzen Pfad, eine Offenlegungsregel, eine Implementierungsgrenze oder mehrere Ursachen spiegeln.

Führen Sie einen Cache-Beobachtungsbeleg. Er ist ein hier vorgeschlagenes redaktionelles Betriebsmittel, kein von der IETF definiertes Protokollobjekt. Bewahren Sie die unveränderten Feldbytes auf und binden Sie sie an Anfrage, Antwort, Beobachtungspunkt und Zeitpunkt. Erfassen Sie für jede erwartete Station die Ausgabekonfiguration, Kennungszuordnung, offengelegten und verborgenen Parameter, Weiterleitungsspur, Identität der nächsten Station und bestätigende Protokolle. Kennzeichnen Sie Lücken als unbekannt, statt Schweigen in Abwesenheit umzudeuten.

Der Beleg ersetzt Cache-Status nicht, sondern hält es in seinem Beweisbereich. Ein gemeldeter hit bleibt Evidenz für einen lokalen Treffer. Eine gemeldete Weiterleitung bleibt Evidenz für die Handlung dieses Caches. Der Zusatz beantwortet die größere Frage: Welcher Teil der Kette konnte melden, welcher meldete tatsächlich und welche unabhängige Evidenz schließt die Lücken?

Quellen