要約

  • RFC 9211では、Cache-StatusはStructured Fieldsのリストであり、各メンバーが一つのキャッシュを表す。オリジンに近い順から利用者に近い順へ並ぶが、経路全体の合意を表すものではない。
  • パラメーターの意味は局所的である。hitでも古い応答はあり得て、ttlは負になり得る。storedとcollapsedは同じメンバーにfwdがある場合だけ解釈できる。
  • 実務では元の順序、観測時刻、観測地点を保持し、自己申告の識別子と検証済みの身元を分ける。詳細の開示は受け手ごとに決め、欠落を完全性の証明に変えない。

一つの応答に複数の語り手がいる

オリジンから利用者までに、地域エッジ、企業ゲートウェイ、ブラウザーの三つのキャッシュがあるとする。地域エッジは再検証のため転送し、企業ゲートウェイは戻った応答を保存し、ブラウザーは後の要求にローカルで答えたかもしれない。三つの処理は同時に成立する。

Cache-Statusは、それらを単一の結論へ統合しない。報告するキャッシュごとにリストのメンバーを一つ置く。RFC 9211が定める順序は、オリジンに最も近いキャッシュが先、ユーザーエージェントに最も近いキャッシュが後である。後段のhitは、前段のfwdを取り消さない。

新しいメンバーを加えるキャッシュは、既存のメンバーを維持することが推奨される。これにより経路上の判断を追いやすくなる。ただし、完全な経路図にはならない。キャッシュは常時報告することも、設定時だけ、あるいはデバッグ要求時だけ報告することもできる。パラメーターも任意である。

したがって、見えないメンバーを「存在しなかった」と読むべきではない。途中でHTTPフィールドが変更される可能性もある。証拠として言えるのは、特定の観測地点で特定の応答からこの列を受け取った、という範囲までだ。

識別子は名乗りであって身分証ではない

各メンバーの冒頭には識別子がある。Structured FieldsのStringまたはTokenで、製品・サービス名、ホスト名、IPアドレス、生成文字列などを使える。固定した内部構成を必ず公開しなくてよい点は、運用上重要である。

一方、その値はメンバーを挿入するキャッシュ自身が選ぶ。構文上正しい識別子だけでは、申告者の真正性を証明できない。管理された環境なら、配備記録、保護された経路、収集点、内部ログが身元との結び付きを補える。未知の経路から届いた同じ文字列には、同じ信頼を与えられない。

記録すべきなのは、申告された識別子、観測地点、期待する送信者との結び付きを示す外部証拠、そして分析者の信頼度である。この四つを「trusted」という一項目にまとめると、判断の根拠が消える。

RFC 9421のHTTP Message Signaturesは、選択したメッセージ要素を別途署名する枠組みを提供する。適切に導入すれば独立した完全性対策になるが、通常のCache-Statusが自動的に署名済みになるわけではない。署名者、鍵、対象要素、中継時の変換についての信頼モデルも必要だ。

hitは鮮度判定ではない

hit=trueが示すのは、そのキャッシュが要求を転送せず、キャッシュから応答を得たことだ。応答が新鮮だったとは限らない。規則上、転送せずに古い応答を提供できる場面なら、それもhitと表現できる。

逆に、保存済みの応答があっても、検証のために要求を上流へ送ったならhitではない。その処理はfwd側に属する。hitとfwdが排他的なのは、今回の要求を当該キャッシュが外へ出したかという分岐を示すためである。

この限定を無視すると指標が崩れる。オリジン負荷の削減、応答の鮮度、利用者間の安全な分離、遅延の短縮は別々の目標だ。hitだけで全てを採点すれば、古い応答や不適切なキー利用を見落とし得る。

集計するときも、どのメンバーが値を出したかを保持する必要がある。経路上のhitを全部足し上げれば、一つの応答を複数回数え、意思決定をした層まで見えなくなる。

fwdの周囲には条件がある

fwdは、キャッシュが知る最も具体的な転送理由をTokenで表す。バイパス、メソッド、URIの不一致、ミス、古さ、検証など、共通の診断分類が用意されている。内部実装を同一化せずに比較可能性を得る仕組みだ。

fwd-statusはfwdと一緒のときだけ意味を持つ。省略された場合、クライアントへ返したステータスが暗黙値となる。storedは転送で得た応答を保存したかを示す。collapsedは、既に進行中の転送要求を再利用できたか、新たな要求を起こしたかを示す。storedとcollapsedをhitメンバーへ移すことはできない。

全パラメーターを表の列にし、欠損をfalseで埋める設計は危うい。「適用外」「非開示」「未観測」が同じ値になってしまう。メンバー単位のパラメーター集合と、その意味が成立する前提を保持すべきだ。

元のフィールドも残しておきたい。Structured Fieldsは厳密な構文を持ち、単純なカンマ分割で代用できない。RFC 9211はRFC 8941を参照して作られ、一般仕様は後にRFC 9651へ置き換えられた。この履歴を、当時のRFC 9211の契約を勝手に読み替える理由にしてはならない。

ttlは各地点のローカルな時計

ttlは、メンバーを追加する時点に近いところで、そのキャッシュが計算した残りの鮮度寿命である。HTTPのAge計算、ヒューリスティック、ローカル設定が影響し、古い応答なら負の値にもなる。

複数メンバーのttlは、共通時計の連続した測定値ではない。保存時刻も対象オブジェクトも方針も異なり得る。差を取ってネットワーク遅延とみなしたり、最小値を「応答全体のTTL」と呼んだりする根拠はない。

有効な分析は局所的だ。あるキャッシュが負のttlを報告しながら転送せず提供する頻度はどうか。ヒューリスティックの変更後に分布は変わったか。正のttlなのに検証が続くのはなぜか。調査対象をメンバーへ戻すことで、設定との照合が可能になる。

観測時刻も不可欠である。Cache-Statusは特定の一応答の処理を示す。次の要求は別経路を通り、別の保存状態や開示設定に出会うかもしれない。異なる二つの列が、どちらも文脈内で正しいことはある。

keyとdetailは公開範囲を選ぶ

keyは実装固有のキャッシュキー表現を載せられる。detailも実装固有の情報であり、同じ値が別キャッシュでは別の意味を持ち得る。相互運用が必要な概念は、登録パラメーターまたは別フィールドにするのがRFC 9211の方向性である。

IANAのCache-Statusパラメーター登録簿はExpert Reviewを採用する。一般的な概念には共通名を、ベンダー固有の拡張には範囲が分かる名前を与えられる。登録簿は意味の衝突を減らすが、個々の応答で誰に見せるかは決めない。

keyの材料、ホスト名、経路やテナントのdetailは、攻撃者にも有用だ。RFC 9211は、キャッシュ構成の探索、利用者活動の推測、タイミング攻撃、キャッシュポイズニングの準備に情報が使われ得ると指摘する。キーを単に難読化しても十分な対策にはならない。

公開応答には粗い処理分類だけ、認証済みの運用診断には追加パラメーター、キー構成は保護ログだけ、という段階化が妥当である。解析できる値だから公開してよい、とは限らない。

来歴を失わない六つの手順

まずフィールド原文と要求文脈、時刻、観測地点を保存する。次にStructured Fieldsの順序付きリストとして解析する。各メンバーを独立した申告として保持し、パラメーターを全体値へ移さない。

さらに、hit/fwdの排他性、fwdに依存する項目、ローカルなttlとdetailを適用する。内容とは別に身元の結び付きと信頼度を評価する。最後に受け手ごとの開示規則を通す。

「地域エッジを名乗るメンバーはmissと保存を申告し、その後のメンバーはhitを申告した。前者は管理基盤と結び付けられるが、後者には独立した認証がない」と書けば、限界を含めて再検証できる。「全体はhit」とだけ書くより、運用判断に耐える。

情報源