Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 9875 Cloudflare
Category: Standards Track October 2025
ISSN: 2070-1721
This specification introduces a means of describing the relationships between stored responses in HTTP caches, grouping them by associating a stored response with one or more strings.
この仕様では、HTTP キャッシュに保存された応答間の関係を記述し、保存された応答を 1 つ以上の文字列に関連付けることによってグループ化する手段を導入しています。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9875.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9875 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Notational Conventions
2. The Cache-Groups Response Header Field
2.1. Identifying Grouped Responses
2.2. Cache Behaviour
2.2.1. Invalidation
3. The Cache-Group-Invalidation Response Header Field
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Author's Address
HTTP caching [HTTP-CACHING] operates at the granularity of a single resource; the freshness of one stored response does not affect that of others. This granularity can make caching more efficient -- for example, when a page is composed of many assets that have different requirements for caching.
HTTP キャッシュ [HTTP-CACHING] は、単一リソースの粒度で動作します。保存された 1 つの応答の鮮度は、他の応答の鮮度には影響しません。この粒度により、キャッシュの効率が向上します。たとえば、ページがキャッシュの要件が異なる多くのアセットで構成されている場合です。
However, there are also cases where the relationship between stored responses could be used to improve cache efficiency.
ただし、保存された応答間の関係を使用してキャッシュ効率を向上できる場合もあります。
For example, it is often necessary to invalidate a set of related resources. This might be because a state-changing request has side effects on other resources, or it might be purely for administrative convenience (e.g., "invalidate this part of the site"). Grouping responses together provides a dedicated way to express these relationships, instead of relying on things like URL structure.
たとえば、関連するリソースのセットを無効にすることが必要になることがよくあります。これは、状態変更リクエストが他のリソースに副作用をもたらすためである可能性もあれば、単に管理上の便宜のためである可能性もあります (例: 「サイトのこの部分を無効にする」など)。応答をグループ化すると、URL 構造などに依存するのではなく、これらの関係を表現するための専用の方法が提供されます。
In addition to sharing invalidation events, the relationships indicated by grouping can also be used by caches to optimise their operation (e.g., to inform the operation of cache eviction algorithms).
無効化イベントの共有に加えて、グループ化によって示される関係は、キャッシュの動作を最適化するために (たとえば、キャッシュ追い出しアルゴリズムの動作を通知するために) キャッシュによって使用することもできます。
Section 2 introduces a means of describing the relationships between stored responses in HTTP caches, by associating those responses with one or more groups that reflect those relationships. It also describes how caches can use that information to apply invalidation events to members of a group.
セクション 2 では、HTTP キャッシュに保存された応答間の関係を、それらの応答をそれらの関係を反映する 1 つ以上のグループに関連付けることによって記述する手段を紹介します。また、キャッシュがその情報を使用してグループのメンバーに無効化イベントを適用する方法についても説明します。
Section 3 introduces one new source of such events: an HTTP response header field that allows a state-changing response to trigger a group invalidation.
セクション 3 では、このようなイベントの新しいソースの 1 つを紹介します。それは、状態変更応答によってグループの無効化をトリガーできるようにする HTTP 応答ヘッダー フィールドです。
These mechanisms operate within a single cache, across the stored responses associated with a single origin server (see Section 2.1). They do not address the issues of synchronising state between multiple caches (e.g., in a hierarchy or mesh), nor do they facilitate association of stored responses from disparate origins.
これらのメカニズムは、単一のオリジン サーバーに関連付けられた保存された応答にわたって、単一のキャッシュ内で動作します (セクション 2.1 を参照)。これらは、複数のキャッシュ (階層またはメッシュ内など) 間での状態の同期の問題には対処しておらず、異なる送信元からの保存された応答の関連付けも促進しません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This specification uses the following terminology from [STRUCTURED-FIELDS]: List, String, and Parameter.
この仕様では、[STRUCTURED-FIELDS] のリスト、文字列、パラメータという用語を使用します。
The Cache-Groups response header field is a List of Strings (Sections 3.1 and 3.3.3 of [STRUCTURED-FIELDS]). Each member of the List is a value that identifies a group that the response belongs to. These Strings are opaque -- while they might have some meaning to the server that creates them, the cache does not have any insight into their structure or content (beyond uniquely identifying a group).
Cache-Groups 応答ヘッダー フィールドは文字列のリストです ([STRUCTURED-FIELDS] のセクション 3.1 および 3.3.3)。リストの各メンバーは、応答が属するグループを識別する値です。これらの文字列は不透明です。文字列を作成するサーバーにとっては何らかの意味があるかもしれませんが、キャッシュはその構造や内容について (グループを一意に識別する以外には) 洞察できません。
HTTP/1.1 200 OK
Content-Type: application/javascript
Cache-Control: max-age=3600
Cache-Groups: "scripts"
The ordering of members is not significant. Unrecognised Parameters are to be ignored.
メンバーの順序は重要ではありません。認識されないパラメータは無視されます。
Implementations MUST support at least 32 groups in a field value, with up to at least 32 characters in each member. Note that generic limitations on HTTP field lengths may constrain the size of this field value in practice.
実装では、フィールド値で少なくとも 32 のグループをサポートし、各メンバーで最大 32 文字をサポートする必要があります。実際には、HTTP フィールドの長さに関する一般的な制限により、このフィールド値のサイズが制限される可能性があることに注意してください。
Two responses stored in the same cache are considered to belong to the same group when all of the following conditions are met:
次の条件がすべて満たされる場合、同じキャッシュに保存されている 2 つの応答は同じグループに属しているとみなされます。
1. They both contain a Cache-Groups response header field that contains the same String (in any position in the List), when compared character-by-character (case sensitive).
1. どちらにも、文字ごとに比較すると (大文字と小文字が区別されます)、同じ文字列 (リスト内の任意の位置) を含む Cache-Groups 応答ヘッダー フィールドが含まれています。
2. They both share the same URI origin (per Section 4.3.1 of [HTTP]).
2. 両方とも同じ URI オリジンを共有します ([HTTP] のセクション 4.3.1 による)。
A cache that invalidates a stored response MAY invalidate any stored responses that share groups (per Section 2.1) with that response. Note that further grouped invalidations are not triggered by a grouped invalidation; i.e., this mechanism does not cascade.
保存された応答を無効にするキャッシュは、その応答とグループ (セクション 2.1 に従って) を共有する保存された応答を無効にしてもよい(MAY)。さらにグループ化された無効化は、グループ化された無効化によってトリガーされないことに注意してください。つまり、このメカニズムはカスケードしません。
Cache extensions can explicitly strengthen the requirement above. For example, a targeted cache control header field [TARGETED] might specify that caches processing it are required to invalidate such responses.
キャッシュ拡張機能により、上記の要件を明示的に強化できます。たとえば、ターゲット キャッシュ制御ヘッダー フィールド [TARGETED] は、そのような応答を無効にするためにキャッシュ処理が必要であることを指定する場合があります。
The Cache-Group-Invalidation response header field is a List of Strings (Sections 3.1 and 3.3.3 of [STRUCTURED-FIELDS]). Each member of the List is a value that identifies a group that the response invalidates, per Section 2.2.1.
Cache-Group-Invalidation 応答ヘッダー フィールドは文字列のリストです ([STRUCTURED-FIELDS] のセクション 3.1 および 3.3.3)。リストの各メンバーは、セクション 2.2.1 に従って、応答によって無効化されるグループを識別する値です。
For example, following a POST request that has side effects on two cache groups, the corresponding response could indicate that stored responses associated with either or both of those groups should be invalidated with:
たとえば、2つのキャッシュ・グループに副作用があるPOSTリクエストの後、対応するレスポンスは、これらのグループのいずれかまたは両方に関連付けられた格納されたレスポンスを次のように無効にする必要があることを示す可能性があります。
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Group-Invalidation: "eurovision-results", "australia"
The Cache-Group-Invalidation header field MUST be ignored on responses to requests that have a safe method (e.g., GET; see Section 9.2.1 of [HTTP]).
Cache-Group-Invalidation ヘッダフィールドは、安全なメソッド (例: GET; [HTTP] のセクション 9.2.1 を参照) を持つリクエストへの応答では無視されなければなりません (MUST)。
A cache that receives a Cache-Group-Invalidation header field on a response to an unsafe request MAY invalidate any stored responses that share groups (per Section 2.1) with any of the listed groups.
安全でないリクエストへの応答で Cache-Group-Invalidation ヘッダーフィールドを受信したキャッシュは、リストされたグループのいずれかと (セクション 2.1 に従って) グループを共有する、保存された応答を無効にしてもよい(MAY)。
Cache extensions can explicitly strengthen the requirement above. For example, a targeted cache control header field [TARGETED] might specify that caches processing it are required to respect the Cache-Group-Invalidation signal.
キャッシュ拡張機能により、上記の要件を明示的に強化できます。たとえば、ターゲット キャッシュ制御ヘッダー フィールド [TARGETED] は、キャッシュ処理が Cache-Group-Invalidation 信号に従う必要があることを指定する場合があります。
The ordering of members is not significant. Unrecognised Parameters are to be ignored.
メンバーの順序は重要ではありません。認識されないパラメータは無視されます。
Implementations MUST support at least 32 groups in a field value, with up to at least 32 characters in each member. Note that generic limitations on HTTP field lengths may constrain the size of this field value in practice.
実装では、フィールド値で少なくとも 32 のグループをサポートし、各メンバーで最大 32 文字をサポートする必要があります。実際には、HTTP フィールドの長さに関する一般的な制限により、このフィールド値のサイズが制限される可能性があることに注意してください。
IANA has added the following entries to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":
IANA は、「ハイパーテキスト転送プロトコル (HTTP) フィールド名レジストリ」に次のエントリを追加しました。
Field Name:
フィールド名:
Cache-Groups
キャッシュグループ
Status:
状態：
permanent
永続
Reference:
参照：
RFC 9875
RFC 9875
Field Name:
フィールド名:
Cache-Group-Invalidation
キャッシュグループの無効化
Status:
状態：
permanent
永続
Reference:
参照：
RFC 9875
RFC 9875
This mechanism allows resources that share an origin to invalidate each other. Because of this, origins that represent multiple parties (sometimes referred to as "shared hosting") might allow one party to group its resources with those of others or to send signals that have side effects upon them.
このメカニズムにより、オリジンを共有するリソースが相互に無効化できるようになります。このため、複数のパーティを表すオリジン (「共有ホスティング」と呼ばれることもあります) では、あるパーティがそのリソースを他のパーティのリソースとグループ化したり、それらのパーティに副作用をもたらすシグナルを送信したりできる可能性があります。
Shared hosts that wish to mitigate these risks can control access to the header fields defined in this specification.
これらのリスクを軽減したい共有ホストは、この仕様で定義されているヘッダー フィールドへのアクセスを制御できます。
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[HTTP-CACHING]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[STRUCTURED-FIELDS]
Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/info/rfc9651>.
[TARGETED] Ludin, S., Nottingham, M., and Y. Wu, "Targeted HTTP Cache
Control", RFC 9213, DOI 10.17487/RFC9213, June 2022,
<https://www.rfc-editor.org/info/rfc9213>.
Thanks to Stephen Ludin for his review and suggestions.
Stephen Ludin のレビューと提案に感謝します。
Mark Nottingham
Cloudflare
Melbourne
Australia
Email: mnot@mnot.net
URI: https://www.mnot.net/