要約

  • ターゲットフィールドを実装するキャッシュは、順序付きターゲットリストから最初の有効かつ空でないフィールドを選ぶ。対象に含めていないフィールドで挙動を変えてはならない。
  • そのため、CDN-Cache-Control が正しくても、同じ応答がホップごとに保存、保存拒否、別フィールドによる制御という異なる結果を生み得る。

明示的に仮想のリリースを考える。オリジンは Cache-Control: no-store と CDN-Cache-Control: max-age=600 を送る。最初の CDN は後者を認識し、応答を 10 分保存する。下流の企業キャッシュはそのフィールドを対象にしておらず、no-store に従う。別の CDN はベンダー固有フィールドをリストの上位に置き、そちらを選ぶ。それでもダッシュボードは「キャッシュ方針 600 秒」という一つの結果しか残さない。

ヘッダーが虚偽なのではない。ヘッダーに意味を与える選択過程がダッシュボードから消えている。

RFC 9213 は、固有のフィールド名によって対象キャッシュまたはキャッシュ群を示す応答フィールドを定義する。CDN-Cache-Control はその標準例である。値にはキャッシュ指示の意味が使われる一方、実装キャッシュは順序付きターゲットリストも保持する。リストは固定、設定可能、あるいはリクエストごとの生成でもよい。認識可能なフィールドが複数あれば、リスト順で最初の有効かつ空でないものを選ぶ。

選択の効果は大きい。ターゲットフィールドを選んだキャッシュは、その値で応答の方針を決め、その応答の通常の Cache-Control と Expires を無視する。リスト上に有効な候補がなければ、RFC 9111 の通常の HTTP キャッシュ制御へ戻る。したがって、準拠する二つのキャッシュが同一バイトを受け取っても、リストが違えば判断は異なり得る。

適用範囲も優先順位と同じく重要だ。リストにないターゲットフィールドは、そのキャッシュの挙動を変えてはならず、転送されなければならない。非 CDN キャッシュは CDN-Cache-Control を見ても適用しない。適用する CDN は通常、下流 CDN のためにフィールドを転送するが、RFC 9213 は望ましくない場合の削除も認める。観測地点に見えたフィールドは、前後の全ホップが同じ集合を受け取った証拠ではない。

構文解析も独立した境界になる。ターゲットフィールドは Structured Fields の辞書であり、見た目が Cache-Control に似ていてもエラー処理は交換できない。空または無効な値は無視され、フォールバックが作動し得る。文字列だけを保存して解析結果を残さない監視は、キャッシュが受理しなかったフィールドへ挙動を誤帰属する。

鮮度も方針を選んだキャッシュに対して相対的である。RFC 9213 の例では、CDN は 3,600 秒、他の共有キャッシュは 600 秒、残るキャッシュは 60 秒を鮮度寿命として扱える。1,800 秒後、応答は CDN では新鮮で、他では古い。矛盾ではなく、適用方針が違う。これをチェーン全体の一状態へ平坦化することが運用上の誤りである。

複数方針の平坦化は安全上の問題にもなる。RFC 9213 は、混乱によって機微情報が意図せず再利用される可能性を警告する。オリジンで正しいフィールド送信を確認しても、各キャッシュの認識、選択、解析、削除、実際の再利用までは証明できない。

必要なのはホップ別キャッシュ判断記録である。重要なキャッシュごとに、種別と識別子、順序付きリスト、受信フィールド、解析結果、選択フィールド、実効指示、鮮度入力、フォールバック、転送または削除、保存・再利用の観測を結び付ける。未知のホップは推測で埋めず、未知として残す。

この記録は編集上の運用統制であり、IETF が定義するプロトコルオブジェクトではない。一つの有効なフィールドからチェーン全体の結論を作らないための仕組みである。

情報源