rfc9875.original.xml   rfc9875.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.3. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
8) --> -ietf-httpbis-cache-groups-07" number="9875" submissionType="IETF" updates="" ob
<?rfc tocindent="yes"?> soletes="" category="std" consensus="true" tocInclude="true" sortRefs="true" sym
<?rfc strict="yes"?> Refs="true" version="3" xml:lang="en">
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-httpbis-cache-groups-07" category="std" consensus="true" tocInclude="true"
sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.28.1 -->
<front> <front>
<title>HTTP Cache Groups</title> <title abbrev="HTTP Cache Groups">HTTP Cache Groups</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-cache-groups-07" <seriesInfo name="RFC" value="9875"/>
/>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham"> <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
<organization/>
<address> <address>
<postal> <postal>
<postalLine>Prahran</postalLine> <postalLine>Prahran</postalLine>
<postalLine>Australia</postalLine> <postalLine>Australia</postalLine>
</postal> </postal>
<email>mnot@mnot.net</email> <email>mnot@mnot.net</email>
<uri>https://www.mnot.net/</uri> <uri>https://www.mnot.net/</uri>
</address> </address>
</author> </author>
<date/> <date month="September" year="2025"/>
<area>Web and Internet Transport</area> <area>WIT</area>
<workgroup>HTTP</workgroup> <workgroup>httpbis</workgroup>
<keyword>HTTP, Caching, Invalidation</keyword> <keyword>HTTP</keyword>
<abstract> <keyword>Caching</keyword>
<?line 48?> <keyword>Invalidation</keyword>
<abstract>
<t>This specification introduces a means of describing the relationships between stored responses in HTTP caches, "grouping" them by associating a stored respon se with one or more strings.</t> <t>This specification introduces a means of describing the relationships between stored responses in HTTP caches, "grouping" them by associating a stored respon se with one or more strings.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-groups/"/>.
</t>
<t>
Discussion of this document takes place on the
HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.or
g"/>),
which is archived at <eref target="https://lists.w3.org/Archives/Public/
ietf-http-wg/"/>.
Working Group information can be found at <eref target="https://httpwg.o
rg/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/httpwg/http-extensions/labels/cache-gro
ups"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 52?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>HTTP caching <xref target="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. </t> <t>HTTP caching <xref target="RFC9111"/> operates at the granularity of a single resource; the freshness of one stored response does not affect that of ot hers. This granularity can make caching more efficient -- for example, when a pa ge is composed of many assets that have different requirements for caching.</t>
<t>However, there are also cases where the relationship between stored res ponses could be used to improve cache efficiency.</t> <t>However, there are also cases where the relationship between stored res ponses could be used to improve cache efficiency.</t>
<t>For example, it is often necessary to invalidate a set of related resou rces. This might be because a state-changing request has side effects on other r esources, or it might be purely for administrative convenience (e.g., "invalidat e this part of the site"). Grouping responses together provides a dedicated way to express these relationships, instead of relying on things like URL structure. </t> <t>For example, it is often necessary to invalidate a set of related resou rces. This might be because a state-changing request has side effects on other r esources, or it might be purely for administrative convenience (e.g., "invalidat e this part of the site"). Grouping responses together provides a dedicated way to express these relationships, instead of relying on things like URL structure. </t>
<!-- [rfced] Will readers understand what "it" refers to here?
Original:
In addition to sharing invalidation events, the relationships
indicated by grouping can also be used by caches to optimise their
operation; for example, it could be used to inform the operation of
cache eviction algorithms.
Perhaps:
In addition to sharing invalidation events, the relationships
indicated by grouping can also be used by caches to optimise their
operation; for example, grouping could be used to inform the operation of
cache eviction algorithms.
Or:
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).
-->
<t>In addition to sharing invalidation events, the relationships indicated by grouping can also be used by caches to optimise their operation; for example , it could be used to inform the operation of cache eviction algorithms.</t> <t>In addition to sharing invalidation events, the relationships indicated by grouping can also be used by caches to optimise their operation; for example , it could be used to inform the operation of cache eviction algorithms.</t>
<t><xref target="cache-groups"/> introduces a means of describing the rela tionships between stored responses in HTTP caches, by associating those response s with one or more groups that reflect those relationships. It also describes ho w caches can use that information to apply invalidation events to members of a g roup.</t> <t><xref target="cache-groups"/> introduces a means of describing the rela tionships between stored responses in HTTP caches, by associating those response s with one or more groups that reflect those relationships. It also describes ho w caches can use that information to apply invalidation events to members of a g roup.</t>
<t><xref target="cache-group-invalidation"/> introduces one new source of such events: a HTTP response header field that allows a state-changing response to trigger a group invalidation.</t> <t><xref target="cache-group-invalidation"/> introduces one new source of such events: an HTTP response header field that allows a state-changing response to trigger a group invalidation.</t>
<t>These mechanisms operate within a single cache, across the stored respo nses associated with a single origin server (see <xref target="identify"/>). The y 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 response s from disparate origins.</t> <t>These mechanisms operate within a single cache, across the stored respo nses associated with a single origin server (see <xref target="identify"/>). The y 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 response s from disparate origins.</t>
<section anchor="notational-conventions"> <section anchor="notational-conventions">
<name>Notational Conventions</name> <name>Notational Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
<t>This specification uses the following terminology from <xref target="STRUCTUR </t>
ED-FIELDS"/>: List, String, Parameter.</t> <t>This specification uses the following terminology from <xref target="RFC9651"
/>: List, String, and Parameter.</t>
</section> </section>
</section> </section>
<section anchor="cache-groups"> <section anchor="cache-groups">
<name>The Cache-Groups Response Header Field</name> <name>The Cache-Groups Response Header Field</name>
<t>The Cache-Groups HTTP Response Header is a List of Strings (Sections <x
ref target="STRUCTURED-FIELDS" section="3.1" sectionFormat="bare"/> and <xref ta <!-- [rfced] Section 3.3.1 of [STRUCTURED-FIELDS] is titled "Integers". Was
rget="STRUCTURED-FIELDS" section="3.3.1" sectionFormat="bare"/> of <xref target= the text/reference below instead meant to point to Section 3.3.3, which is
"STRUCTURED-FIELDS"/>). Each member of the list is a value that identifies a gro titled "Strings"?
up that the response belongs to. These strings are opaque -- while they might ha
ve some meaning to the server that creates them, the cache does not have any ins Also, may we update "Cache-Groups HTTP Response Header" in the first sentence
ight into their structure or content (beyond uniquely identifying a group).</t> to "Cache-Groups response header field" for consistency with other instances
in the document?
Original:
The Cache-Groups HTTP Response Header is a List of Strings (Sections
3.1 and 3.3.1 of [STRUCTURED-FIELDS]).
...
The Cache-Group-Invalidation response header field is a List of
Strings (Sections 3.1 and 3.3.1 of [STRUCTURED-FIELDS]).
Perhaps:
The Cache-Groups response header field is a List of Strings (Sections
3.1 and 3.3.3 of [STRUCTURED-FIELDS]).
...
The Cache-Group-Invalidation response header field is a List of
Strings (Sections 3.1 and 3.3.3 of [STRUCTURED-FIELDS]).
-->
<t>The Cache-Groups HTTP Response Header is a List of Strings (Sections <x
ref target="RFC9651" section="3.1" sectionFormat="bare"/> and <xref target="RFC9
651" section="3.3.1" sectionFormat="bare"/> of <xref target="RFC9651"/>). Each m
ember of the list is a value that identifies a group that the response belongs t
o. 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 c
ontent (beyond uniquely identifying a group).</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/javascript Content-Type: application/javascript
Cache-Control: max-age=3600 Cache-Control: max-age=3600
Cache-Groups: "scripts" Cache-Groups: "scripts"
]]></sourcecode> ]]></sourcecode>
<t>The ordering of members is not significant. Unrecognised Parameters are to be ignored.</t> <t>The ordering of members is not significant. Unrecognised Parameters are to be ignored.</t>
<t>Implementations <bcp14>MUST</bcp14> support at least 32 groups in a fie ld value, with up to at least 32 characters in each member. Note that generic li mitations on HTTP field lengths may constrain the size of this field value in pr actice.</t> <t>Implementations <bcp14>MUST</bcp14> support at least 32 groups in a fie ld value, with up to at least 32 characters in each member. Note that generic li mitations on HTTP field lengths may constrain the size of this field value in pr actice.</t>
<section anchor="identify"> <section anchor="identify">
<name>Identifying Grouped Responses</name> <name>Identifying Grouped Responses</name>
skipping to change at line 94 skipping to change at line 122
Content-Type: application/javascript Content-Type: application/javascript
Cache-Control: max-age=3600 Cache-Control: max-age=3600
Cache-Groups: "scripts" Cache-Groups: "scripts"
]]></sourcecode> ]]></sourcecode>
<t>The ordering of members is not significant. Unrecognised Parameters are to be ignored.</t> <t>The ordering of members is not significant. Unrecognised Parameters are to be ignored.</t>
<t>Implementations <bcp14>MUST</bcp14> support at least 32 groups in a fie ld value, with up to at least 32 characters in each member. Note that generic li mitations on HTTP field lengths may constrain the size of this field value in pr actice.</t> <t>Implementations <bcp14>MUST</bcp14> support at least 32 groups in a fie ld value, with up to at least 32 characters in each member. Note that generic li mitations on HTTP field lengths may constrain the size of this field value in pr actice.</t>
<section anchor="identify"> <section anchor="identify">
<name>Identifying Grouped Responses</name> <name>Identifying Grouped Responses</name>
<t>Two responses stored in the same cache are considered to belong to th e same group when all of the following conditions are met:</t> <t>Two responses stored in the same cache are considered to belong to th e same group when all of the following conditions are met:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>They both contain a Cache-Groups response header field that conta ins the same String (in any position in the List), when compared character-by-ch aracter (case sensitive).</t> <t>They both contain a Cache-Groups response header field that conta ins the same String (in any position in the List), when compared character-by-ch aracter (case sensitive).</t>
</li> </li>
<li> <li>
<t>They both share the same URI origin (per <xref section="4.3.1" se ctionFormat="of" target="HTTP"/>).</t> <t>They both share the same URI origin (per <xref section="4.3.1" se ctionFormat="of" target="RFC9110"/>).</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="cache-behaviour"> <section anchor="cache-behaviour">
<name>Cache Behaviour</name> <name>Cache Behaviour</name>
<section anchor="invalidation"> <section anchor="invalidation">
<name>Invalidation</name> <name>Invalidation</name>
<t>A cache that invalidates a stored response <bcp14>MAY</bcp14> inval
idate any stored responses that share groups (per <xref target="identify"/>) wit <t>A cache that invalidates a stored response <bcp14>MAY</bcp14> inval
h that response. Note that further grouped invalidations are not triggered by a idate any stored responses that share groups (per <xref target="identify"/>) wit
grouped invalidation; i.e., this mechanism does not "cascade."</t> h that response. Note that further grouped invalidations are not triggered by a
<t>Cache extensions can explicitly strengthen the requirement above. F grouped invalidation; i.e., this mechanism does not "cascade".</t>
or example, a targeted cache control header field <xref target="TARGETED"/> migh <t>Cache extensions can explicitly strengthen the requirement above. F
t specify that caches processing it are required to invalidate such responses.</ or example, a targeted cache control header field <xref target="RFC9213"/> might
t> specify that caches processing it are required to invalidate such responses.</t
>
</section> </section>
</section> </section>
</section> </section>
<section anchor="cache-group-invalidation"> <section anchor="cache-group-invalidation">
<name>The Cache-Group-Invalidation Response Header Field</name> <name>The Cache-Group-Invalidation Response Header Field</name>
<t>The Cache-Group-Invalidation response header field is a List of Strings (Sections <xref target="STRUCTURED-FIELDS" section="3.1" sectionFormat="bare"/> and <xref target="STRUCTURED-FIELDS" section="3.3.1" sectionFormat="bare"/> of <xref target="STRUCTURED-FIELDS"/>). Each member of the list is a value that ide ntifies a group that the response invalidates, per <xref target="invalidation"/> .</t> <t>The Cache-Group-Invalidation response header field is a List of Strings (Sections <xref target="RFC9651" section="3.1" sectionFormat="bare"/> and <xref target="RFC9651" section="3.3.1" sectionFormat="bare"/> of <xref target="RFC965 1"/>). Each member of the list is a value that identifies a group that the respo nse invalidates, per <xref target="invalidation"/>.</t>
<t>For example, following a POST request that has side effects on two cach e groups, the corresponding response could indicate that stored responses associ ated with either or both of those groups should be invalidated with:</t> <t>For example, following a POST request that has side effects on two cach e groups, the corresponding response could indicate that stored responses associ ated with either or both of those groups should be invalidated with:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
Cache-Group-Invalidation: "eurovision-results", "australia" Cache-Group-Invalidation: "eurovision-results", "australia"
]]></sourcecode> ]]></sourcecode>
<t>The Cache-Group-Invalidation header field <bcp14>MUST</bcp14> be ignore
d on responses to requests that have a safe method (e.g., GET; see <xref section <t>The Cache-Group-Invalidation header field <bcp14>MUST</bcp14> be ignore
="9.2.1" sectionFormat="of" target="HTTP"/>).</t> d on responses to requests that have a safe method (e.g., GET; see <xref section
="9.2.1" sectionFormat="of" target="RFC9110"/>).</t>
<t>A cache that receives a Cache-Group-Invalidation header field on a resp onse to an unsafe request <bcp14>MAY</bcp14> invalidate any stored responses tha t share groups (per <xref target="identify"/>) with any of the listed groups.</t > <t>A cache that receives a Cache-Group-Invalidation header field on a resp onse to an unsafe request <bcp14>MAY</bcp14> invalidate any stored responses tha t share groups (per <xref target="identify"/>) with any of the listed groups.</t >
<t>Cache extensions can explicitly strengthen the requirement above. For e xample, a targeted cache control header field <xref target="TARGETED"/> might sp ecify that caches processing it are required to respect the Cache-Group-Invalida tion signal.</t> <t>Cache extensions can explicitly strengthen the requirement above. For e xample, a targeted cache control header field <xref target="RFC9213"/> might spe cify that caches processing it are required to respect the Cache-Group-Invalidat ion signal.</t>
<t>The ordering of members is not significant. Unrecognised Parameters are to be ignored.</t> <t>The ordering of members is not significant. Unrecognised Parameters are to be ignored.</t>
<t>Implementations <bcp14>MUST</bcp14> support at least 32 groups in a fie ld value, with up to at least 32 characters in each member. Note that generic li mitations on HTTP field lengths may constrain the size of this field value in pr actice.</t> <t>Implementations <bcp14>MUST</bcp14> support at least 32 groups in a fie ld value, with up to at least 32 characters in each member. Note that generic li mitations on HTTP field lengths may constrain the size of this field value in pr actice.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA should perform the following tasks:</t> <t>IANA has added the following entries to the "Hypertext Transfer Proto
<section anchor="http-field-names"> col (HTTP) Field Name Registry":</t>
<name>HTTP Field Names</name> <dl spacing="compact" newline="false">
<t>Enter the following into the Hypertext Transfer Protocol (HTTP) Field <dt>Field Name:</dt><dd>Cache-Groups</dd>
Name Registry:</t> <dt>Status:</dt><dd>permanent</dd>
<ul spacing="normal"> <dt>Reference:</dt><dd>RFC 9875</dd>
<li> </dl>
<t>Field Name: Cache-Groups</t> <dl spacing="compact" newline="false">
</li> <dt>Field Name:</dt><dd>Cache-Group-Invalidation</dd>
<li> <dt>Status:</dt><dd>permanent</dd>
<t>Status: permanent</t> <dt>Reference:</dt><dd>RFC 9875</dd>
</li> </dl>
<li>
<t>Reference: RFC nnnn</t>
</li>
<li>
<t>Comments:</t>
</li>
<li>
<t>Field Name: Cache-Group-Invalidation</t>
</li>
<li>
<t>Status: permanent</t>
</li>
<li>
<t>Reference: RFC nnnn</t>
</li>
<li>
<t>Comments:</t>
</li>
</ul>
</section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This mechanism allows resources that share an origin to invalidate each other. Because of this, <t>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 hostin g") might allow origins that represent multiple parties (sometimes referred to as "shared hostin g") might allow
one party to group its resources with those of others, or to send signals which have side effects upon them.</t> one party to group its resources with those of others or to send signals that ha ve side effects upon them.</t>
<t>Shared hosts that wish to mitigate these risks can control access to th e header fields defined in this specification.</t> <t>Shared hosts that wish to mitigate these risks can control access to th e header fields defined in this specification.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC9111" to="HTTP-CACHING"/>
<displayreference target="RFC9651" to="STRUCTURED-FIELDS"/>
<displayreference target="RFC9213" to="TARGETED"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="HTTP"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<front> 10.xml"/>
<title>HTTP Semantics</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<author fullname="R. Fielding" initials="R." role="editor" surname=" 11.xml"/>
Fielding"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.96
<author fullname="M. Nottingham" initials="M." role="editor" surname 51.xml"/>
="Nottingham"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<author fullname="J. Reschke" initials="J." role="editor" surname="R 19.xml"/>
eschke"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<date month="June" year="2022"/> 74.xml"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="HTTP-CACHING">
<front>
<title>HTTP Caching</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document defines HTTP caches and the associated header fields that control
cache behavior or indicate cacheable response messages.</t>
<t>This document obsoletes RFC 7234.</t>
</abstract>
</front>
<seriesInfo name="STD" value="98"/>
<seriesInfo name="RFC" value="9111"/>
<seriesInfo name="DOI" value="10.17487/RFC9111"/>
</reference>
<reference anchor="STRUCTURED-FIELDS">
<front>
<title>Structured Field Values for HTTP</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
>
<author fullname="P-H. Kamp" surname="P-H. Kamp"/>
<date month="September" year="2024"/>
<abstract>
<t>This document describes a set of data types and associated algo
rithms that are intended to make it easier and safer to define and handle HTTP h
eader and trailer fields, known as "Structured Fields", "Structured Headers", or
"Structured Trailers". It is intended for use by specifications of new HTTP fie
lds.</t>
<t>This document obsoletes RFC 8941.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9651"/>
<seriesInfo name="DOI" value="10.17487/RFC9651"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="TARGETED"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
<front> 13.xml"/>
<title>Targeted HTTP Cache Control</title>
<author fullname="S. Ludin" initials="S." surname="Ludin"/>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
>
<author fullname="Y. Wu" initials="Y." surname="Wu"/>
<date month="June" year="2022"/>
<abstract>
<t>This specification defines a convention for HTTP response heade
r fields that allow cache directives to be targeted at specific caches or classe
s of caches. It also defines one such header field, the CDN-Cache-Control respon
se header field, which is targeted at content delivery network (CDN) caches.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9213"/>
<seriesInfo name="DOI" value="10.17487/RFC9213"/>
</reference>
</references> </references>
</references> </references>
<?line 179?>
<section anchor="acknowledgements"> <section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Thanks to Stephen Ludin for his review and suggestions.</t> <t>Thanks to <contact fullname="Stephen Ludin"/> for his review and sugges tions.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1Z624jtxX+P0/BaoHCLjSy5d0mWW2a1PF6Y6Ne2/UFQRAE
ATVDSaxnhhOSY61iOM/SZ+mT9TuHHGlGdrZt0AIt0ABZS7wcnut3LkrTNPHa
F2oiTm5uLsWRzBZKfG1NU7tETqdW3U+S3GSVLHEkt3LmU638LF14X0+1SzO6
kM75Qrr/aZJLj4MPbw9vjh+TDF/mxq4mwvk8SXRtJ8LbxvmD/f3X+wfJnVot
jc3D20N+XFfzoTit7mWhQUqbKsGJO6YfjiXSKjkR36ipkFWOo17ZSnlxY2Xl
amN9kjiPnR9kYSqwslIucaW0/ocfG+OVm4jKJLWeiO+8yYYC/+gqV5UfCofL
Vs0cPq3K+MFbnWErM2Ut44cSh7Glq0JX6vskuVdVoyaJEF0mhfCrGq9/A+Yh
UtAoVheG9EjKc5O9Pfq7nI+Mne9hr5S6mIi1dtPl/I/Ll7SJPWmzxeZeoZ13
o7C5d4gtfa/c3mUzLXS21yVAZK2qzebqXPtFMx1Bjvg6/0nVB68qB3W7vUJO
VeH2uoZNwq1UO9eolA9MRO9AIhu/MBZqSPGkgHag6PcjcW68h/wLWfJycKP3
0t5t70ASWemf2OQTXqkN7FiEz0Kk4tLKBWzM3zPTVJ786hDOZOErkpdVUGFZ
Gf9H+mcEx+CNxuqNCpbL5ajd3UuSytgSz96zDcl4E3H17uj1eLwfv6dHh0cn
p+dft+tjrF/fXN0e3dxeHb9N350en729Dpuf/H4MN69mXZI3h1dfH98cvw0n
DsYvkwQepP2KNq+Pz95NxAA7osJ/gyRJ01TIKUmVwZVvFtoJV6tMz3TGyoFq
vTV5kyknpCgVvF6YmciVy6yekq95RLBVBZ92C107MVV+qVQFdzZW5dhEoFQO
BHQVwp5tCacesDlBZEBUSjFdCekcQkSSrfDeFgWxhGMIxBnsJ0psccRUczcK
gpQ6zwuVJMkLClRmm2M6Wb9KZB8eump+fBSmVhbQAQE9SzOH3ZtCWiiNZAUb
uFaQlM40NlNv+NQMXxeVcqwP4mmb2dyAJAwv5GymMiIN+nQWt60bCVZ2961M
VojKO7XmlEVUM9hCw4YCEsLUQn2QZV2ooVguoGQpajlXAqQINYwDB3ijlBXr
UnkX3l3Ie3CkwYklUlb92GirGFyYaHwSijwxS3Wv7JCExPOS/i+cwQky4ZIX
t23+yyZH6BQ5tkVDnHkjdFlbcx9k3AiXrfDyu65w2pNMZgagEJWC+zlpV0yg
RWtFllGsUuYlvMsWarVb6vnC0+tTlUlwwC6Fk2m2kNWcVEyKUI70A8fXOXME
Y+HlKhhqQ3NIXge21kTrBu+uWH0yL3WlKYwoDiF1BZwmuZTYUaP5CL7e4dsT
bzWSBPFOunTaq8HuKOB2YKtVoDdzxXyQ2sAghWGucgpPCLyUrBP1obbkiTjo
tqKRUofzSuZRTysiD+E8mduJQsPfbq/OKJIQLZAIhjiFW+W55vgHdbeQFGUb
zdM6fIQT09PwR4KL3CGe2whn52Y/an1huoo4QE+Y2utSO/YsbWNEguKbvsdD
+08divGP+VhfI1mjg91rxgC8jdIA8FESWDw8dNMJIOA/iXJbqIbExTZqjz/B
tMBUCFvUBUXADrNt2JE49UGjkU3QWphlq1TSd8MKBZl1jggGlXUNv33GnLRZ
qnIKfArIx7xsKyzt3uwrj+So1FKEkCEarskWkfoEBFkza4hcwC/h2jOtYFPm
VBaFWbrn4jReAYfA/Pkc1yJ7PUFGlMQoCEpFd7UrXYvvrGldbfCcRRoKmVkT
YuepLVvDUaiRndZ34UvgC/hjgZVixymFvKKpstOz1ePjLgGQWiEHhAyQ5218
Cq5qWL1uVWULa8AkScgCr72qbAqv65ZJ16IIs7/QkAdl2IpdBllod4hXLD3m
6dGZzHShmdza8UJMPJFvZk2JtOAARnQ8SEURkrx4QTUT35SFOGJAY99jBQvU
0oKKaScG72+vbwbD8FecX/Dnq+M/356iXKHP1yeHZ2frD0k8cX1ycXv2dvNp
c/Po4v374/O34TJWRW8pGbw//BY7VI0PLi5vTi/OD88GpBhGVTQPDWU1zlue
0UZTzQ58JCNKl7TRktOdr44u//bX8SvY7jcoig7G49fw5/Dls/Gnr/CFkmx4
zVQImvCV1JwgipS0bJKigJ1qqLxAvFMmQSBWglIlVPm770gz30/E59OsHr/6
Ii6QwL3FVme9RdbZ05Unl4MSn1l65pm1NnvrW5ru83v4be97q/fO4udfUoMi
0vFnX36RPFtJNpzOqHIyFOSMhcoib5rCzFfBFR8enpS6j48TcYbUOhTXXOwN
xSWctYQ5LfspBVpoJNPQSIqrFitOAry8Y3h5eNHD/ODGvXuMTduXNYERvU/x
EzhANIJPxXnFiZejMbvHyxF9okNPJQAcHOOliK1t1qe+KtAHfjUtVAcM0ZyJ
Ar7xekhAkTd0RIb48IZxxq0LYXZ7U0sUNVQuLhe6UAEUQtXCZaBDV8hJjk1g
AvIFIOOnMrS8PtiqDAk+5NJ1QctUqMIEVjBZhJiJqXtdRxA4oQ7yFIw7U7Uy
0FFTaXBGuSciZSjzWcxdWPPnn3/mviktqd6bKy7c98bQK1p4cfGn5CgQTG+4
3aU8Fr1r7y/yXlJg1z4JRqWj1lB/Jj+koPWHl5/s7yddg6MTCjfcgF4OHgFM
U1ztUBUdU6EOYkPWit258iNxW1mVGSxQGbL2SNfFnXlFaEv1FFUvhEohewsO
f9fUND+gpqNQEp7w8qBN/YzyISmyZwxD8iFXML3zSHHUuDGPyOEbF+NWOHrU
XFWQKIO7lbrlwMQaJTxSqGruFyiXUU3CZFTGMp5SYfqTCu4KHXQ4oudqelpn
BHFIFqcdi7J6oZardZ55eLHOjVDz0nRSUMxJ7YPQY3Q30iRxg5s2lHrB7dcu
S0dDhIROCCgcI2uDMCAQCtlgGRhpkiTjmJ2nqPDZRyVrvAcGH6lR4g234SLg
gtghMggLtGE6Ns98huBjN/ZrPNsheda2S6erdP1F7FCfhXCsiMS9QlQcdLml
WlxtHr69Om1LkR1UOWKNS+JVC0dkZ0KgkNPDxO0rhRDWqNFo7UVvAEam6pZ3
SXIY7RErybaLcc/058gTvf4MunhScjCZIEZ098h5p3oK/h4r4HCx69GzxnJL
NI9+1mU42JnCNZaJodWQzx5+I/RIjYbBvdcV4wboBjBGBvOPBklADrGZXHGF
jcYLCKR9QYJaDiNVRaxed9hCTtHxjkSvv5XCSzvnoiSoNwt41fe3h4d2noNS
JEB4SKqr6IqhOkRvSB0yN2mh9InP51sdM1fja1s8mz/Tnjf8E7k03fKXj9J7
Pqz+K5Nsx9WHIrpor/HZHllsUEeKywtAfDtciBOYpxMGvzTR+iEUYrY1NjCR
9zqf0Pm23XWMo3/UsCjNkQI2GT5YKdRKxtBDoRrb6Y204ebkX87GHrGxt/Bl
kfyS9ZFwVUNjDAqgFEyjyXFU5ct2rtpJxL/oQj3P4VS6Sbai42LczUYTdKdg
gC0541SwMHnbWCHG3ojQxbUI+np0sI2gPShE/lc0Ce9njo/wSlOIXiNLLXrF
zLSe8u8FULreCQNQCRdG/8toRooII5GP+AiVarIY/b+k+/UlnTg9PD+kxp8L
MBl7f16MqAGvW4/eOj2ddHduwsUG8xMyxjmUievH1ItvXWibB3ECGLGEIuHX
tRlOXlrjTQY/2iFaux1iyExzGriu8FTaWZ/0yjhsXUNBDWp90C5lBYth7Urx
HDyj3w4ffku/ijw+Yvko/tz2MZI9P/vV5KFewEzDY/9tFd/0i5E4EVuPobvx
j5iN1V8/zbPb8Ph6hFovjL6jyYdJHPK0IEaTYwrr9cSJBtOUGXeoT/QadqMx
pLIx/pDGBvx6LpBJaKQ52I3BzKwmNAMkGjyZjhM63xUgFncmMBV+DuHhOs2a
FbJ8iF76sUFDjtCzdjNnU/MAW5Xw0+sNK1GkpXYLHmSigJ6HTMlTcQ2/ZJhr
sUlmGQ/lgvd1kcqJXM101bYl26MMqpvo96apzO7IlIfZXWWWhcrn4RcVsqGs
7pj0tVc1oehZg2zO02wiZ9W9VksuaVyDKtWx7UH37xxWSHEiHwAA
<!-- [rfced] Are the quotation marks needed around "grouping" and "cascade" in
these sentences?
Original:
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.
...
Note that further grouped invalidations are not triggered by a
grouped invalidation; i.e., this mechanism does not "cascade."
Perhaps:
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.
...
Note that further grouped invalidations are not triggered by a
grouped invalidation; i.e., this mechanism does not cascade.
-->
<!-- [rfced] We note inconsistencies in the terms below throughout the
text. Please review all instances and let us know if any updates are
needed.
list vs. List
string vs. String
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 29 change blocks. 
303 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.48.