要約

  • RFC 9111では、安全でないリクエストに対するエラーでない応答を見たキャッシュは対象URIを無効化しなければならない。ただし、その義務が生じるのは当該リクエストが通過したキャッシュである。
  • 全体でパージできたと主張するには、経路の網羅、関連URI、アプリケーション固有の派生キーについて別の証拠が要る。

明確に仮想の事例を考える。クライアントがPUTを送り、オリジンが204 No Contentを返すと、管理画面は直ちに「グローバルパージ完了」と表示した。書き込みはアプリケーションキャッシュと一つの地域ゲートウェイを通った。しかし、その経路外にある別のエッジは、古いオブジェクトから組み立てた一覧ページを配信し続ける。204という応答だけでは、このエッジも一覧用の派生キーも特定できない。

これはHTTPキャッシュの欠陥ではない。プロトコル上の規則と運用上の主張の境界である。RFC 9110は、定義された意味が本質的に読み取り専用であるメソッドを安全とし、GET、HEAD、OPTIONS、TRACEを安全なメソッドとしている。状態を変え得るメソッドは扱いが異なる。RFC 9111によれば、キャッシュは安全でないリクエストをオリジンまで書き通さなければならず、転送して対応する応答を受ける前に自ら応答を作ってはならない。

その応答が、限定された無効化義務を発生させる。安全でないメソッドに対するエラーでない応答を受けたキャッシュは、対象URIを無効化する。ここでエラーでない応答とは2xxまたは3xxである。無効化とは、一致する保存済み応答を削除するか、再利用前に必ず検証させる無効状態にすることだ。古い応答を無条件で使わせないための規則であり、あらゆる複製が消えたという証明ではない。

RFC 9111は、ほかのURIの無効化も認めている。LocationやContent-Locationが対象URIと同一オリジンなら候補になり得る。だが、この許可は万能な依存関係探索ではない。異なるオリジンの候補URIをこの規則で無効化してはならず、変更対象からアプリケーションが生成する商品ページ、一覧、検索結果、フラグメント、サロゲートキーをすべて推測する義務もない。

さらに、トポロジーの限界がある。仕様は、この仕組みがグローバルな無効化を保証しないと明記する。状態変更リクエストが無効化できるのは、そのリクエストが通過したキャッシュにある応答だけだ。別の読み取り経路にのみ存在するキャッシュは、ローカルな義務を起動するプロトコルイベントを受け取っていない。複数CDN、シールドを迂回する経路、地域分割、APIとページの別経路は、この境界を運用上の統制課題に変える。

混同してはいけない主張は三つある。「オリジンが書き込みを受理した」は応答についての事実である。「通過したキャッシュが対象URIを無効化した」はプロトコルが求めるローカル処理である。「すべての利用者が新しい状態を見る」は経路、キーの派生、検証を含むシステム全体の主張である。第一の事実だけで全階層の第二の処理は証明できず、両方があっても第三の結論には届かない。

この差を埋めるには、無効化経路レシートが必要になる。これは本稿が提案する編集上の統制概念であり、IETFが定義するプロトコルオブジェクトではない。安全でないリクエストと応答を、それを運んだキャッシュインスタンスに結び付ける。各層の正規化済み対象URIとローカル処理を記録し、対象への必須処理とLocation／Content-Locationへの任意処理を区別する。さらに、一覧、検索、フラグメント、サロゲートキーの対応表と、重要な各配信経路からのキャッシュ回避プローブを残す。

書き込み後の問いは、「204が世界中を消したか」ではない。「どの経路が書き込みを運び、どのキャッシュが動き、どの識別子が対象となり、どの独立した読み取りが新状態を確認したか」である。ここまで揃って初めて、プロトコルに適合するローカル処理をシステム全体の証拠へ変えられる。

情報源