HTTP キャッシュグループ

本書はインターネット標準化トラック文書です。

本書はインターネット技術標準化タスクフォース（IETF）の成果物です。本書は IETF コミュニティのコンセンサスを表しており、パブリックレビューを受け、さらにインターネット技術指導グループ（IESG）による公開の承認を受けています。インターネット標準に関するさらなる情報はRFC 7841のセクション2を参照してください。

本書の現状、訂正情報、およびフィードバックの提供方法についてはhttps://www.rfc-editor.org/info/rfc9875でご確認いただけます。

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

HTTPキャッシュ[HTTP-CACHING]は、単一リソースの粒度で動作します。一つの保存レスポンスの新鮮さは他のレスポンスには影響しません。この粒度はキャッシュを効率的にすることができ、例えばページが異なるキャッシュ要件を持つ多くのアセットで構成される場合に有効です。

しかし、保存レスポンス間の関係性を活用することで、キャッシュ効率を向上できる場合もあります。

例えば、関連するリソースのセットを無効化する必要がよくあります。これは状態を変更するリクエストが他のリソースにも副作用を及ぼす場合や、単に管理上の理由（例:「サイトのこの部分を無効化」）による場合があります。レスポンスをグループ化することは、これらの関係を表現する専用の方法を提供し、URL構造などに頼る必要がなくなります。

無効化イベントの共有に加えて、グループ化によって示される関係は、キャッシュがその動作を最適化するため（例: キャッシュ排除アルゴリズムの運用を通知するなど）にも利用できます。

セクション2では、HTTPキャッシュ内の保存レスポンス同士の関係を記述するために、それらのレスポンスをそれらの関係を反映した1つ以上のグループへ関連付ける手段を導入します。また、キャッシュがその情報を利用してグループ内メンバーに無効化イベントを適用する方法についても述べます。

セクション3では、そのようなイベントの新たな発生源として、状態変更レスポンスがグループ無効化を引き起こすことを可能にするHTTP応答ヘッダーフィールドを紹介します。

これらの仕組みは、一つのキャッシュ内、かつ単一オリジンサーバーに関連付けられた保存レスポンス間で動作します（セクション2.1参照）。それらは、複数のキャッシュ間で状態を同期する問題（例: 階層やメッシュ内）や、異なるオリジンの保存レスポンスの関連付けには対応していません。

Cache-Groups応答ヘッダーフィールドは、文字列のリスト（3.1 および 3.3.3 [STRUCTURED-FIELDS] 参照）です。リストの各メンバーは、そのレスポンスが属するグループを識別する値です。これらの文字列は不透明であり、発行サーバーには意味があるかもしれませんが、キャッシュはその構造や内容を（グループを一意に識別する以外は）解釈しません。

HTTP/1.1 200 OK
Content-Type: application/javascript
Cache-Control: max-age=3600
Cache-Groups: "scripts"

メンバーの順序に意味はありません。認識されないパラメータは無視するものとします。

実装は1つのフィールド値内に少なくとも32個のグループと各メンバーは最大32文字までをサポートしなければなりません（MUST）。ただし、HTTPフィールド長の一般的な制限により実際のサイズが制約される場合があります。

Cache-Group-Invalidation応答ヘッダーフィールドは文字列のリストです（3.1, 3.3.3 [STRUCTURED-FIELDS]参照）。リストの各メンバーは、そのレスポンスが無効化するグループ（セクション2.2.1参照）を識別する値です。

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Group-Invalidation: "eurovision-results", "australia"

Cache-Group-Invalidation ヘッダーフィールドは、安全なメソッドのリクエスト（例: GET、セクション9.2.1 [HTTP] 参照）へのレスポンスでは無視されなければなりません（MUST）。

キャッシュは、非安全リクエストに対するレスポンスでCache-Group-Invalidation ヘッダーフィールドを受信した場合、そのリスト内いずれかのグループとグループを共有する（セクション2.1参照）保存レスポンスを無効化してもよい（MAY）です。

キャッシュ拡張によって、上記の要件を明示的に強めることができます。たとえば、ターゲット型キャッシュ制御ヘッダーフィールド[TARGETED]は、キャッシュがCache-Group-Invalidationシグナルを尊重することを要求する場合があります。

メンバーの順序に意味はありません。認識されないパラメータは無視するものとします。

実装は1つのフィールド値内に少なくとも32個のグループと各メンバーは最大32文字までをサポートしなければなりません（MUST）。一般的なHTTPフィールド長の制約により実際のサイズが制限される場合があります。

フィールド名:

Cache-Groups

ステータス:

permanent

参照:

RFC 9875

フィールド名:

Cache-Group-Invalidation

ステータス:

permanent

参照:

RFC 9875

この仕組みにより、同じオリジンを共有するリソース相互の無効化が可能になります。そのため、マルチパーティ（「共有ホスティング」と呼ばれることもあります）を代表するオリジンでは、あるパーティが他者のリソースと自身のリソースを同じグループにしたり、他者への副作用を持つ信号を送信できる場合があります。

こうしたリスクを低減したい共有ホストは、本仕様で定義されるヘッダーフィールドへのアクセスを制御できます。

Stephen Ludin氏のレビューとご意見に感謝します。