要約

  • Cache-Control: only-if-cachedは保存済み応答だけを求める。これを尊重するキャッシュは、条件に合う応答か504を返す。
  • この504はオリジンへ一度も接続せず生成できるため、証明するのはキャッシュ限定取得の失敗であり、オリジンの停止ではない。

明確に仮想の可用性プローブを考える。運用者は設定スナップショットがエッジに常駐しているか調べるため、Cache-Control: only-if-cached付きのGETを送る。エッジには条件を満たす保存済み応答がなく、504を返す。監視規則はステータスだけを見てオリジンのタイムアウトと判断し、担当者を呼び出す。だがキャッシュは要求どおり転送せず、オリジンには何も届いていない。

曖昧さは504の一般的な意味とキャッシュでの特別な使い方から生じる。RFC 9110はGateway Timeoutを、要求の完了に必要な上流サーバーからゲートウェイやプロキシが適時に応答を得られなかった状態と定義する。一方RFC 9111は、only-if-cachedを尊重するキャッシュに、他の条件にも合う保存済み応答か504を返すよう示す。後者では、上流取得をしないこと自体がクライアントの指定である。

つまり、この指示は実験の問いを変える。「オリジンは応答できるか」ではなく、「このキャッシュは今、再利用可能な保存済み応答だけで要求を満たせるか」を問う。結果を通常のエンドツーエンド試験として読むと、異なる制御経路が混ざる。

保存されたバイトがあるだけでも足りない。対象とメソッド、Varyが指定する要求フィールド、検証条件が一致し、応答が新鮮、検証済み、または古いまま利用可能でなければならない。URIに対応するデータがあっても適格な候補がない場合がある。したがって504は「何も保存されていない」ではなく、「この条件で使えるものがない」を意味し得る。

ステータスだけでは、どのキャッシュが判断したかも分からない。ブラウザ、企業プロキシ、CDN、ゲートウェイを通る場合、応答したノード、そこで見た指示、候補と除外理由、転送を止めた事実を保存する必要がある。これがなければ、ダッシュボードは証拠ではなく慣例で責任を割り当てる。

オリジン障害とキャッシュ常駐の失敗では、担当者も復旧操作も利用者への影響も異なる。通常プローブが同時に成功しても、必ずしも間欠障害ではない。二つのプローブが別の問いを発した証拠かもしれない。

キャッシュ限定リクエストの判断記録を作る。これはIETFが定義したプロトコル要素ではなく、本稿の運用上の提案である。対象、メソッド、全Cache-Control指示、キャッシュの識別子と検索キー、候補、Vary比較、鮮度または期限切れ利用権、検証要件、選択またはミス、転送判断、上流への接続試行の有無を結び付ける。その後で、保存済み応答の利用可否、転送方針、上流応答の待ち時間のどれに属するか分類する。

上流試行がないことはオリジンの健全性を証明しない。この観測ではオリジン障害を証明できない、という境界を示す。到達性には制約なしの別プローブが必要だ。孤立したコードではなく、要求文脈と実行記録が原因を支える。

情報源