要約

  • Cache-Groups が結ぶのは、同じキャッシュにあり、同じオリジンに属し、大文字小文字まで一致する文字列を持つ保存済み応答だけである。
  • Cache-Group-Invalidation の処理はローカルかつ任意で、連鎖せず、別のキャッシュへ同期されない。

一つの更新が複数の URI を古くすることは珍しくない。商品データを直せば、詳細、検索結果、集計の各応答が影響を受ける。RFC 9875 は、URL の形から関係を推測する代わりに、その関係を応答自身が示す仕組みを定めた。

Cache-Groups は Structured Fields の String の List である。文字列はキャッシュにとって不透明であり、業務上の意味や階層を解釈しない。順序に意味はなく、未知のパラメータは無視される。実装は一つのフィールドで少なくとも 32 グループ、各値について少なくとも 32 文字を扱う必要があるが、HTTP フィールド全体の制限は残る。

同じグループになる条件は厳密だ。二つの応答が同じキャッシュに保存され、文字列が大文字小文字を含めて一字ずつ同じで、URI オリジンも共通していなければならない。別オリジンの同名ラベルは無関係である。別キャッシュに同じラベルがあっても、共有された台帳にはならない。

Cache-Group-Invalidation は、状態を変え得るリクエストへの応答で、無効化対象となり得るグループを示す。GET のような安全なメソッドへの応答に付いた場合、キャッシュは無視しなければならない。フィールド値だけを記録し、リクエストメソッドを落とした監査ログでは処理条件を再現できない。

ここでの規範語は MAY である。同じグループのメンバーを無効化してよいが、すべてのキャッシュに同じ動作を義務づけてはいない。RFC 9213 の Targeted HTTP Cache Control のような拡張で、対象となるキャッシュ群への要求を強めることはできる。どのプロファイルが有効だったかは、別の設定証拠である。

無効化は必ずしも消去ではない。RFC 9111 では、保存済み応答を削除するか、再利用前に必須の検証を要する無効状態に印を付けることを意味する。したがって「無効化済み」という記録だけでは、バイトが消えたのか、次回に再検証されたのか、新しい表現が補充されたのかは分からない。

グループは推移的にも広がらない。A と B が第一のグループを共有し、B と C が第二のグループを共有しても、A の無効化が B を経由して C まで到達するわけではない。連鎖は禁止され、処理時点でそのキャッシュが実際に保持していたメンバーだけが候補になる。

さらに、仕様は単一キャッシュ、単一オリジンという境界を明記する。階層やメッシュ内の複数キャッシュを同期せず、異なるオリジンの応答も結ばない。一つの経路で信号が観測されても、別のエッジが受信、理解、実行したとは言えない。

運用証拠は段階ごとに必要になる。オリジンでの状態変更、フィールド発行権限、メソッドと応答、各中継点での受信、実装対応、ローカル方針、当時のメンバー集合、無効化判断、削除か無効印か、後続の検証または再充填、重要経路ごとのアプリケーションカナリアを分離して残す。

共有ホスティングでは権限が制御面になる。RFC 9875 は、一方の主体が同じオリジンにいる他方の資源を自分のグループに入れたり、副作用を与える信号を送ったりする可能性を警告する。応答ヘッダーを自由に追加できることと、他のテナントに影響するグループを操作する権限は同じではない。

IANA の HTTP Field Name Registry は二つのフィールドを permanent な List として登録している。これは名前と参照先を固定する。現行製品での実装、経路上の保持、処理の実行、利用者の結果までは証明しない。

出典