Zusammenfassung

  • Cache-Control: only-if-cached verlangt ausschließlich eine gespeicherte Antwort; ein Cache, der die Direktive beachtet, soll eine passende Antwort oder 504 liefern.
  • Dieser 504 kann ohne Kontakt zum Origin entstehen und belegt deshalb den Fehlschlag der Cache-only-Abfrage, nicht die Nichterreichbarkeit des Ursprungsservers.

Betrachten wir eine ausdrücklich hypothetische Verfügbarkeitssonde. Der Betreiber möchte prüfen, ob eine Konfiguration am Edge liegt, und sendet einen GET mit Cache-Control: only-if-cached. Der Cache findet keine gespeicherte Antwort, die alle Bedingungen erfüllt, und gibt 504 zurück. Eine Alarmregel sieht nur den Status, meldet einen Origin-Timeout und ruft dessen Team. Der Cache hat jedoch genau die Anweisung erfüllt: keine Weiterleitung, kein Origin-Kontakt.

Die Mehrdeutigkeit entsteht aus der allgemeinen und der cachespezifischen Verwendung. RFC 9110 definiert Gateway Timeout grundsätzlich als ausbleibende rechtzeitige Antwort eines Upstream-Servers, den ein Gateway zur Bearbeitung erreichen musste. RFC 9111 gibt einem Cache, der only-if-cached beachtet, zwei Ergebnisse vor: eine mit den übrigen Anforderungen vereinbare gespeicherte Antwort oder 504. Im zweiten Zweig hat der Client gerade verlangt, keinen Upstream-Abruf zu machen.

Die Direktive verändert also die Frage. Sie prüft nicht, ob der Origin antworten kann, sondern ob dieser Cache die Anfrage allein mit einer zulässig wiederverwendbaren Antwort erfüllen kann. Wer das Ergebnis als End-to-End-Test liest, vermischt zwei Kontrollpfade.

Gespeicherte Bytes allein reichen nicht. Ziel und Methode müssen passen, die von Vary benannten Felder übereinstimmen, Validierungspflichten erfüllt sein und die Antwort frisch, validiert oder zur veralteten Ausgabe zugelassen sein. Ein Cache kann Daten für den URI besitzen und dennoch keinen geeigneten Kandidaten haben. Der 504 kann „unter diesen Bedingungen nichts verwendbar“ bedeuten, nicht „nichts gespeichert“.

Auch die entscheidende Cache-Stufe ist aus dem Status nicht erkennbar. Browsercache, Unternehmensproxy, CDN und Gateway können beteiligt sein. Ermittler benötigen die Identität des antwortenden Punkts, die dort beobachtete Direktive, Kandidaten und Ablehnungsgründe sowie die unterdrückte Weiterleitung. Sonst weist das Dashboard Verantwortung aus Gewohnheit zu.

Origin-Störung und eine fehlende geeignete Kopie am Edge haben andere Eigentümer, Maßnahmen und Kundenfolgen. Wenn eine gewöhnliche Sonde neben der Cache-only-Sonde erfolgreich ist, belegt das nicht zwingend Intermittenz. Beide haben unterschiedliche Fragen gestellt.

Führen Sie einen Cache-only-Entscheidungsbeleg. Er ist ein hier vorgeschlagenes Betriebsmittel, kein von der IETF definiertes Protokollelement. Verbinden Sie Ziel, Methode, Direktiven, Cache-Identität und Suchschlüssel, Kandidaten, Vary-Vergleich, Frische oder Berechtigung zur veralteten Nutzung, Validierung, Auswahl oder Miss, Weiterleitungsentscheidung und Upstream-Versuchsspur. Erst danach folgt die Einordnung als Cache-Eignung, Weiterleitungspolitik oder Upstream-Zeitproblem.

Kein Upstream-Versuch beweist keinen gesunden Origin. Er beweist nur, dass diese Beobachtung dessen Ausfall nicht belegen kann. Für Erreichbarkeit braucht es eine getrennte Sonde ohne Cache-only-Einschränkung. Anfragekontext und Ausführungsspur, nicht der isolierte Status, tragen die Ursache.

Quellen