要約

  • Cache-Status の各メンバーは、報告したキャッシュが対応する要求と応答をどう処理したかを表し、hit と fwd には明確な局所的意味がある。
  • フィールドを送る時期は各キャッシュが決め、パラメーターは任意で、開示も制限され得るため、短いリストは他のキャッシュや判断が存在しなかった証明にはならない。

明示的に仮想の障害レビューを考える。応答には Cache-Status: edge; hit だけがある。ダッシュボードは緑色の箱を一つ描き、「単一キャッシュによる配信」と判定し、上流システムは関与しなかったと記録する。このメンバー自体は正しいかもしれない。エッジは今回の要求を転送せず、保存済み応答で処理した。しかし、その保存済み応答は以前の交換でオリジン寄りの別キャッシュから取得され、そのキャッシュは自分のフィールドを付けなかった可能性がある。示されるのは今回エッジが行ったことまでで、保存済み応答がそこに至った全履歴ではない。

RFC 9211 は Cache-Status に明確だが限定された役割を与える。リストの各メンバーは、要求を処理し、報告することを選んだキャッシュを表す。複数の値が保持される場合、オリジンに近いキャッシュから利用者に近いキャッシュの順に並ぶ。自分の値を追加するキャッシュは、既存値を保持することが推奨される。この規則により、可視化されたチェーンの調査には大きな価値がある。

ただし、リストが網羅的だという保証はない。仕様上、フィールドを追加するのが適切かどうかはキャッシュが判断する。すべての応答に追加する構成もあれば、設定やデバッグ用の要求で有効化されたときだけ追加する構成もある。キャッシュ状態、利用状況、キー構成の情報は攻撃を助け得るため、セキュリティ方針による省略や選択的開示も認められる。メンバーがないことは「ここで報告されていない」ことを示すにすぎず、「ここにキャッシュがない」とは限らない。

パラメーターも局所的な事実を述べる。hit は、報告キャッシュが今回の要求を転送せず、キャッシュから応答を得たことを意味する。fwd は、そのキャッシュが要求をオリジン方向へ転送し、uri-miss、vary-miss、stale、request などの理由を付けられることを意味する。これらは運用に有用な証拠であり、境界のない色表示に置き換えるべきではない。

局所的な真実は完全なトポロジーではない。fwd-status は次ホップのサーバーから返された状態であり、その次ホップはオリジンではなく別の中継装置かもしれない。キャッシュ識別子は製品名、ホスト名、アドレス、生成文字列などになり得る。任意の詳細値も実装固有である。構成と観測点がなければ、同じ表示名が同じ役割を保証せず、異なる表示名だけで独立した設備を証明することもできない。

時間の範囲も重要だ。Cache-Status は対応する今回の要求と応答を記述する。hit だけでは、保存済み応答がいつ、どのチェーンから取得されたかは分からない。そのオブジェクトの履歴でオリジンが一度も参照されなかった証明にもならない。異なるディレクティブ、認証情報、Vary 値、鮮度条件を持つ近接要求の扱いも説明しない。RFC 9111 のキャッシュ判断は要求ごとに行われる。

この区別は障害原因の誤認を防ぐ。fwd=stale; fwd-status=304 は、報告キャッシュが次ホップから 304 を受け取ったことを裏付ける。しかし、次ホップがオリジンであること、全キャッシュが報告したこと、別の観測点でも同じ判断だったことまでは単独で示せない。情報が少ない理由は短い経路、開示方針、実装限界、またはその組み合わせである。

キャッシュ観測レシートを残すべきだ。これは本稿が提案する運用上の管理手段で、IETF が定義したプロトコルオブジェクトではない。生のフィールド値を要求、応答、観測点、時刻に結び付ける。想定する各キャッシュについて、当該要求種別での送信設定、識別子の対応、開示・非開示パラメーター、転送記録、次ホップの実体、照合ログを記録する。空白は「不明」とし、沈黙を不存在に変換しない。

このレシートは Cache-Status を置き換えず、その証拠範囲を保つ。報告された hit は局所的 hit の証拠であり、報告された転送はそのキャッシュの転送動作の証拠である。追加記録は、チェーンのどこが報告可能で、どこが実際に報告し、何が欠落部分を独立に裏付けたかという、より大きな問いに答える。

出典