rfc9842.original.xml   rfc9842.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.18 (Ruby 3.3. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
3) --> -ietf-httpbis-compression-dictionary-19" number="9842" category="std" updates=""
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft obsoletes="" consensus="true" submissionType="IETF" tocInclude="true" sortRefs=
-ietf-httpbis-compression-dictionary-19" category="std" consensus="true" submiss "true" symRefs="true" version="3" xml:lang="en">
ionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.23.0 -->
<front> <front>
<title>Compression Dictionary Transport</title> <title abbrev="Compression Dictionary Transport">Compression Dictionary Tran
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-compression-dict sport</title>
ionary-19"/> <seriesInfo name="RFC" value="9842"/>
<author initials="P." surname="Meenan" fullname="Patrick Meenan" role="edito r"> <author initials="P." surname="Meenan" fullname="Patrick Meenan" role="edito r">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<email>pmeenan@google.com</email> <email>pmeenan@google.com</email>
</address> </address>
</author> </author>
<author initials="Y." surname="Weiss" fullname="Yoav Weiss" role="editor"> <author initials="Y." surname="Weiss" fullname="Yoav Weiss" role="editor">
<organization>Shopify Inc</organization> <organization>Shopify Inc</organization>
<address> <address>
<email>yoav.weiss@shopify.com</email> <email>yoav.weiss@shopify.com</email>
</address> </address>
</author> </author>
<date year="2024" month="August" day="28"/> <date year="2025" month="August"/>
<area>ART</area> <area>ART</area>
<workgroup>HTTP</workgroup> <workgroup>HTTP</workgroup>
<keyword>compression dictionary</keyword> <keyword>compression dictionary</keyword>
<keyword>shared brotli</keyword> <keyword>shared brotli</keyword>
<keyword>zstandard dictionary</keyword> <keyword>zstandard dictionary</keyword>
<keyword>delta compression</keyword> <keyword>delta compression</keyword>
<abstract> <abstract>
<?line 77?>
<t>This document specifies a mechanism for dictionary-based compression in the <t>This document specifies a mechanism for dictionary-based compression in the
Hypertext Transfer Protocol (HTTP). By utilizing this technique, clients and Hypertext Transfer Protocol (HTTP). By utilizing this technique, clients and
servers can reduce the size of transmitted data, leading to improved performance servers can reduce the size of transmitted data, leading to improved performance
and reduced bandwidth consumption. This document extends existing HTTP compressi on and reduced bandwidth consumption. This document extends existing HTTP compressi on
methods and provides guidelines for the delivery and use of compression methods and provides guidelines for the delivery and use of compression
dictionaries within the HTTP protocol.</t> dictionaries within the HTTP protocol.</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-compression-dictionary/"/>.
</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/compressi
on-dictionary"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 86?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This specification defines a mechanism for using designated <xref targe t="HTTP"/> responses <t>This specification defines a mechanism for using designated HTTP <xref target="RFC9110"/> responses
as an external dictionary for future HTTP responses for compression schemes as an external dictionary for future HTTP responses for compression schemes
that support using external dictionaries (e.g., Brotli <xref target="RFC7932"/> and that support using external dictionaries (e.g., Brotli <xref target="RFC7932"/> and
Zstandard <xref target="RFC8878"/>).</t> Zstandard <xref target="RFC8878"/>).</t>
<t>This document describes the HTTP headers used for negotiating dictionar y usage <t>This document describes the HTTP headers used for negotiating dictionar y usage
and registers content encoding values for compressing with Brotli and Zstandard and registers content-encoding values for compressing with Brotli and Zstandard
using a negotiated dictionary.</t> using a negotiated dictionary.</t>
<t>The negotiation of dictionary usage leverages HTTP's content negotiatio n <t>The negotiation of dictionary usage leverages HTTP's content negotiatio n
(see <xref section="12" sectionFormat="of" target="HTTP"/>) and is usable with a ll versions of HTTP.</t> (see <xref section="12" sectionFormat="of" target="RFC9110"/>) and is usable wit h all versions of HTTP.</t>
<section anchor="use-cases"> <section anchor="use-cases">
<name>Use Cases</name> <name>Use Cases</name>
<t>Any HTTP response can be specified to be used as a compression dictio <t>Any HTTP response can be specified for use as a compression dictionar
nary for y for
future HTTP requests which provides a lot of flexibility. There are two common future HTTP requests, which provides a lot of flexibility. Two common
use cases that are seen frequently:</t> use cases that are seen frequently are described below.</t>
<section anchor="version-upgrade"> <section anchor="version-upgrade">
<name>Version Upgrade</name> <name>Version Upgrade</name>
<t>Using a previous version of a resource as a dictionary for a newer version <t>Using a previous version of a resource as a dictionary for a newer version
enables delivery of a delta-compressed version of the changes, usually enables delivery of a delta-compressed version of the changes, usually
resulting in significantly smaller responses than can be achieved by resulting in significantly smaller responses than what can be achieved by
compression alone.</t> compression alone.</t>
<t>For example:</t> <t>For example:</t>
<figure> <figure>
<name>Version Upgrade Example</name> <name>Version Upgrade Example</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="432" width="424" viewBox="0 0 424 432" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="432" width="424" viewBox="0 0 424 432" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,48 L 8,176" fill="none" stroke="black"/> <path d="M 8,48 L 8,176" fill="none" stroke="black"/>
<path d="M 8,256 L 8,416" fill="none" stroke="black"/> <path d="M 8,256 L 8,416" fill="none" stroke="black"/>
<path d="M 416,48 L 416,176" fill="none" stroke="black"/> <path d="M 416,48 L 416,176" fill="none" stroke="black"/>
<path d="M 416,256 L 416,416" fill="none" stroke="black"/> <path d="M 416,256 L 416,416" fill="none" stroke="black"/>
skipping to change at line 176 skipping to change at line 161
| Content-Encoding: dcb | | Content-Encoding: dcb |
| <delta-compressed app.v2.js resource - 1KB> | | <delta-compressed app.v2.js resource - 1KB> |
|<-------------------------------------------------| |<-------------------------------------------------|
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="common-content"> <section anchor="common-content">
<name>Common Content</name> <name>Common Content</name>
<t>If several resources share common patterns in their responses then it can be <t>If several resources share common patterns in their responses, then it can be
useful to reference an external dictionary that contains those common patterns, useful to reference an external dictionary that contains those common patterns,
effectively compressing them out of the responses. Some examples of this are effectively compressing them out of the responses. Some examples of this are
common template HTML for similar pages across a site and common keys and values common template HTML for similar pages across a site and common keys and values
in API calls.</t> in API calls.</t>
<t>For example:</t> <t>For example:</t>
<figure> <figure>
<name>Common Content Example</name> <name>Common Content Example</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="544" width="440" viewBox="0 0 440 544" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="544" width="440" viewBox="0 0 440 544" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,48 L 8,288" fill="none" stroke="black"/> <path d="M 8,48 L 8,288" fill="none" stroke="black"/>
skipping to change at line 292 skipping to change at line 277
| <delta-compressed page2.html resource - 10KB> | | <delta-compressed page2.html resource - 10KB> |
|<---------------------------------------------------| |<---------------------------------------------------|
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
</section> </section>
<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>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
<?line -18?> </t>
<t>This document uses the following terminology from <xref
<t>This document uses the following terminology from Section 3 of target="RFC9651" sectionFormat="of" section="3"/> to specify
<xref target="STRUCTURED-FIELDS"/> to specify syntax and parsing: Dictionary, St syntax and parsing: Dictionary, String, Inner List, Token, and Byte
ring, Sequence.</t>
Inner List, Token, and Byte Sequence.</t> <t>This document uses the line folding strategies described in <xref tar
<t>This document uses the line folding strategies described in <xref tar get="RFC8792"/>.</t>
get="FOLDING"/>.</t> <t>This document also uses terminology from <xref target="RFC9110"/> and
<t>This document also uses terminology from <xref target="HTTP"/> and <x <xref target="RFC9111"/>.</t>
ref target="HTTP-CACHING"/>.</t>
</section> </section>
</section> </section>
<section anchor="dictionary-negotiation"> <section anchor="dictionary-negotiation">
<name>Dictionary Negotiation</name> <name>Dictionary Negotiation</name>
<section anchor="use-as-dictionary"> <section anchor="use-as-dictionary">
<name>Use-As-Dictionary</name> <name>Use-As-Dictionary</name>
<t>When responding to a HTTP Request, a server can advertise that the re sponse can <t>When responding to an HTTP Request, a server can advertise that the r esponse can
be used as a dictionary for future requests for URLs that match the rules be used as a dictionary for future requests for URLs that match the rules
specified in the Use-As-Dictionary response header.</t> specified in the "Use-As-Dictionary" response header.</t>
<t>The Use-As-Dictionary response header is a Structured Field <t>The "Use-As-Dictionary" response header is a Structured Field
<xref target="STRUCTURED-FIELDS"/> Dictionary with values for "match", "match-de <xref target="RFC9651"/> Dictionary with values for "match", "match-dest", "id",
st", "id",
and "type".</t> and "type".</t>
<section anchor="match"> <section anchor="match">
<name>match</name> <name>"match"</name>
<t>The "match" value of the Use-As-Dictionary header is a String value <t>The "match" value of the "Use-As-Dictionary" response header is a S
that tring value that
provides the URL Pattern to use for request matching (see <xref target="URLPATTE RN"/>).</t> provides the URL Pattern to use for request matching (see <xref target="URLPATTE RN"/>).</t>
<t>The URL Pattern used for matching does not support using regular ex pressions.</t> <t>The URL Pattern used for matching does not support using regular ex pressions.</t>
<t>The following algorithm is used to validate that a given String val ue is a <t>The following algorithm is used to validate that a given String val ue is a
valid URL Pattern that does not use regular expressions and is for the same valid URL Pattern that does not use regular expressions and is for the same
Origin (<xref section="4.3.1" sectionFormat="of" target="HTTP"/>) as the diction ary. It will return TRUE Origin (<xref section="4.3.1" sectionFormat="of" target="RFC9110"/>) as the dict ionary. It will return TRUE
for a valid match pattern and FALSE for an invalid pattern that <bcp14>MUST NOT< /bcp14> be for a valid match pattern and FALSE for an invalid pattern that <bcp14>MUST NOT< /bcp14> be
used:</t> used.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<li>
<t>Let MATCH be the value of "match" for the given dictionary.</t> <t>Let MATCH be the value of "match" for the given dictionary.</t>
</li> </li>
<li> <li>
<t>Let URL be the URL of the dictionary request.</t> <t>Let URL be the URL of the dictionary request.</t>
</li> </li>
<li> <li>
<t>Let PATTERN be a URL pattern created by running the steps to cr eate a <t>Let PATTERN be a URL pattern created by running the steps to cr eate a
URL pattern by setting input=MATCH, and baseURL=URL (see URL pattern by setting input=MATCH and baseURL=URL (see
<xref target="URLPATTERN" section="create" relative="#url-pattern-create"/>).</t > <xref target="URLPATTERN" section="create" relative="#url-pattern-create"/>).</t >
</li> </li>
<li> <li>
<t>If the result of running the "has regexp groups" steps for PATT ERN returns <t>If the result of running the "has regexp groups" steps for PATT ERN returns
TRUE then return FALSE (see <xref target="URLPATTERN" section="has regexp groups " relative="#url-pattern-has-regexp-groups"/>).</t> TRUE, then return FALSE (see <xref target="URLPATTERN" section="has regexp group s" relative="#url-pattern-has-regexp-groups"/>).</t>
</li> </li>
<li> <li>
<t>Return TRUE.</t> <t>Return TRUE.</t>
</li> </li>
</ol> </ol>
<t>The "match" value is required and <bcp14>MUST</bcp14> be included i n the <t>The "match" value is required and <bcp14>MUST</bcp14> be included i n the
Use-As-Dictionary response header for the dictionary to be considered valid.</t> "Use-As-Dictionary" response header for the dictionary to be considered valid.</
<t>Operating at the HTTP-level, the specified match patterns will oper t>
ate on the <t>Operating at the HTTP level, the specified match patterns will oper
percent-encoded version of the URL path (see <xref section="2" sectionFormat="of ate on the
" target="URL"/>).</t> percent-encoded version of the URL path (see <xref section="2" sectionFormat="of
<t>For example the URL "http://www.example.com/düsseldorf" would be en " target="RFC3986"/>).</t>
coded as <t>For example, the URL "http://www.example.com/düsseldorf" would be e
ncoded as
"http://www.example.com/d%C3%BCsseldorf" and a relevant match pattern would be:< /t> "http://www.example.com/d%C3%BCsseldorf" and a relevant match pattern would be:< /t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Use-As-Dictionary: match="/d%C3%BCsseldorf" Use-As-Dictionary: match="/d%C3%BCsseldorf"
]]></sourcecode> ]]></sourcecode>
</section> </section>
<!-- [rfced] In an effort to make the text file reader-friendly and to keep
links to non-RFC references from degrading over time, we would like to
update six reference links that use the "relative" attribute to some more
meaningful text.
Please review the following instances and let us know if these changes are
acceptable.
a)
Current:
(see Part RequestDestination of [FETCH])
Perhaps:
(see "RequestDestination" in Section 5.4 of [FETCH])
b)
Current:
(see Part has regexp groups of [URLPATTERN])
Perhaps:
(see the last list in Section 1.4 of [URLPATTERN])
c)
Current:
(see Part create of [URLPATTERN])
Perhaps:
(see Section 1.4 of [URLPATTERN])
d)
Current:
(see Part match of [URLPATTERN])
Perhaps:
(see "Match" in Section 1.4 of [URLPATTERN])
e)
Current:
(see Part CORS check of [FETCH])
Perhaps:
(see Section 4.9 of [FETCH])
-->
<section anchor="match-dest"> <section anchor="match-dest">
<name>match-dest</name> <name>"match-dest"</name>
<t>The "match-dest" value of the Use-As-Dictionary header is an Inner List of <t>The "match-dest" value of the Use-As-Dictionary header is an Inner List of
String values that provides a list of Fetch request destinations for the String values that provides a list of Fetch request destinations for the
dictionary to match (see <xref target="FETCH" section="RequestDestination" relat ive="#requestdestination"/>).</t> dictionary to match (see <xref target="FETCH" section="RequestDestination" relat ive="#requestdestination"/>).</t>
<t>An empty list for "match-dest" <bcp14>MUST</bcp14> match all destin ations.</t> <t>An empty list for "match-dest" <bcp14>MUST</bcp14> match all destin ations.</t>
<t>For clients that do not support request destinations, the client <b cp14>MUST</bcp14> treat it <t>For clients that do not support request destinations, the client <b cp14>MUST</bcp14> treat it
as an empty list and match all destinations.</t> as an empty list and match all destinations.</t>
<t>The "match-dest" value is optional and defaults to an empty list.</ t> <t>The "match-dest" value is optional and defaults to an empty list.</ t>
</section> </section>
<section anchor="id"> <section anchor="id">
<name>id</name> <name>"id"</name>
<t>The "id" value of the Use-As-Dictionary header is a String value th at specifies <t>The "id" value of the Use-As-Dictionary header is a String value th at specifies
a server identifier for the dictionary. If an "id" value is present and has a a server identifier for the dictionary. If an "id" value is present and has a
string length longer than zero then it <bcp14>MUST</bcp14> be sent to the server in a string length longer than zero, then it <bcp14>MUST</bcp14> be sent to the serve r in a
"Dictionary-ID" request header when the client sends an "Available-Dictionary" "Dictionary-ID" request header when the client sends an "Available-Dictionary"
request header for the same dictionary (see <xref target="available-dictionary"/ >).</t> request header for the same dictionary (see <xref target="available-dictionary"/ >).</t>
<t>The server identifier <bcp14>MUST</bcp14> be treated as an opaque s tring by the client.</t> <t>The server identifier <bcp14>MUST</bcp14> be treated as an opaque s tring by the client.</t>
<t>The server identifier <bcp14>MUST NOT</bcp14> be relied upon by the server to guarantee the <t>The server identifier <bcp14>MUST NOT</bcp14> be relied upon by the server to guarantee the
contents of the dictionary. The dictionary hash <bcp14>MUST</bcp14> be validated before use.</t> contents of the dictionary. The dictionary hash <bcp14>MUST</bcp14> be validated before use.</t>
<t>The "id" value string length (after any decoding) supports up to 10 24 <t>The "id" value string length (after any decoding) supports up to 10 24
characters.</t> characters.</t>
<t>The "id" value is optional and defaults to the empty string.</t> <t>The "id" value is optional and defaults to the empty string.</t>
</section> </section>
<section anchor="type"> <section anchor="type">
<name>type</name> <name>"type"</name>
<t>The "type" value of the Use-As-Dictionary header is a Token value t hat <t>The "type" value of the Use-As-Dictionary header is a Token value t hat
describes the file format of the supplied dictionary.</t> describes the file format of the supplied dictionary.</t>
<t>"raw" is defined as a dictionary format which represents an unforma tted blob of <t>"raw" is defined as a dictionary format that represents an unformat ted blob of
bytes suitable for any compression scheme to use.</t> bytes suitable for any compression scheme to use.</t>
<t>If a client receives a dictionary with a type that it does not unde rstand, it <t>If a client receives a dictionary with a type that it does not unde rstand, it
<bcp14>MUST NOT</bcp14> use the dictionary.</t> <bcp14>MUST NOT</bcp14> use the dictionary.</t>
<t>The "type" value is optional and defaults to "raw".</t> <t>The "type" value is optional and defaults to "raw".</t>
</section> </section>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<section anchor="path-prefix"> <section anchor="path-prefix">
<name>Path Prefix</name> <name>Path Prefix</name>
<!-- [rfced] May we restructure and rephrase Sections 2.1.5.1 and 2.1.5.2 as
follows for readability?
Original (Section 2.1.5.1):
A response that contained a response header:
NOTE: '\' line wrapping per RFC 8792
Use-As-Dictionary: \
match="/product/*", match-dest=("document")
Would specify matching any document request for a URL with a path
prefix of /product/ on the same Origin (Section 4.3.1 of [HTTP]) as
the original request.
Perhaps (Section 2.5.1.1):
A response that contained a response header (as shown below) would
specify matching any document request for a URL with a path prefix of
/product/ on the same Origin (Section 4.3.1 of [HTTP]) as the original
request:
NOTE: '\' line wrapping per RFC 8792
Use-As-Dictionary: \
match="/product/*", match-dest=("document")
...
Original (Section 2.5.1.2):
A response that contained a response header:
Use-As-Dictionary: match="/app/*/main.js"
Would match any path that starts with "/app/" and ends with
"/main.js".
Perhaps (Section 2.5.1.2):
A response that contained a response header (shown
below) would match any path that starts with "/app/" and
ends with "/main.js":
Use-As-Dictionary: match="/app/*/main.js"
-->
<t>A response that contained a response header:</t> <t>A response that contained a response header:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
Use-As-Dictionary: \ Use-As-Dictionary: \
match="/product/*", match-dest=("document") match="/product/*", match-dest=("document")
]]></sourcecode> ]]></sourcecode>
<t>Would specify matching any document request for a URL with a path prefix of <t>Would specify matching any document request for a URL with a path prefix of
/product/ on the same Origin (<xref section="4.3.1" sectionFormat="of" target="H TTP"/>) as the original /product/ on the same Origin (<xref section="4.3.1" sectionFormat="of" target="R FC9110"/>) as the original
request.</t> request.</t>
</section> </section>
<section anchor="versioned-directories"> <section anchor="versioned-directories">
<name>Versioned Directories</name> <name>Versioned Directories</name>
<t>A response that contained a response header:</t> <t>A response that contained a response header:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Use-As-Dictionary: match="/app/*/main.js" Use-As-Dictionary: match="/app/*/main.js"
]]></sourcecode> ]]></sourcecode>
<t>Would match any path that starts with "/app/" and ends with "/mai n.js".</t> <t>Would match any path that starts with "/app/" and ends with "/mai n.js".</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="available-dictionary"> <section anchor="available-dictionary">
<name>Available-Dictionary</name> <name>Available-Dictionary</name>
<t>When a HTTP client makes a request for a resource for which it has an <t>When an HTTP client makes a request for a resource for which it has a
appropriate dictionary, it can add a "Available-Dictionary" request header n
appropriate dictionary, it can add an "Available-Dictionary" request header
to the request to indicate to the server that it has a dictionary available to to the request to indicate to the server that it has a dictionary available to
use for compression.</t> use for compression.</t>
<t>The "Available-Dictionary" request header is a Structured Field <t>The "Available-Dictionary" request header is a Structured Field
<xref target="STRUCTURED-FIELDS"/> Byte Sequence containing the <xref target="SH A-256"/> hash of the <xref target="RFC9651"/> Byte Sequence containing the SHA-256 <xref target="RFC6 234"/> hash of the
contents of a single available dictionary.</t> contents of a single available dictionary.</t>
<t>The client <bcp14>MUST</bcp14> only send a single "Available-Dictiona ry" request header <t>The client <bcp14>MUST</bcp14> only send a single "Available-Dictiona ry" request header
with a single hash value for the best available match that it has available.</t> with a single hash value for the best available match that it has available.</t>
<t>For example:</t> <t>For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=: Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
]]></sourcecode> ]]></sourcecode>
<section anchor="dictionary-freshness-requirement"> <section anchor="dictionary-freshness-requirement">
<name>Dictionary freshness requirement</name> <name>Dictionary Freshness Requirement</name>
<t>To be considered as a match, the dictionary resource <bcp14>MUST</b cp14> be either fresh <t>To be considered as a match, the dictionary resource <bcp14>MUST</b cp14> be either fresh
<xref target="HTTP-CACHING"/> or allowed to be served stale (see eg <xref target ="RFC5861"/>).</t> <xref target="RFC9111"/> or allowed to be served stale (see <xref target="RFC586 1"/>).</t>
</section> </section>
<section anchor="dictionary-url-matching"> <section anchor="dictionary-url-matching">
<name>Dictionary URL matching</name> <name>Dictionary URL Matching</name>
<t>When a dictionary is stored as a result of a "Use-As-Dictionary" di rective, it <t>When a dictionary is stored as a result of a "Use-As-Dictionary" di rective, it
includes a "match" string and optional "match-dest" string that are used to includes a "match" string and an optional "match-dest" string that are used to
match an outgoing request from a client to the available dictionaries.</t> match an outgoing request from a client to the available dictionaries.</t>
<t>To see if an outbound request matches a given dictionary, the follo wing <t>To see if an outbound request matches a given dictionary, the follo wing
algorithm will return TRUE for a successful match and FALSE for no-match:</t> algorithm will return TRUE for a successful match and FALSE for no-match:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>If the current client supports request destinations and a "matc h-dest" <t>If the current client supports request destinations and a "matc h-dest"
string was provided with the dictionary: string was provided with the dictionary:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Let DEST be the value of "match-dest" for the given diction ary.</t> <t>Let DEST be the value of "match-dest" for the given diction ary.</t>
</li> </li>
<li> <li>
<t>Let REQUEST_DEST be the value of the destination for the cu rrent <t>Let REQUEST_DEST be the value of the destination for the cu rrent
request.</t> request.</t>
</li> </li>
<li> <li>
<t>If DEST is not an empty list and if REQUEST_DEST is not in the DEST list <t>If DEST is not an empty list and if REQUEST_DEST is not in the DEST list
of destinations, return FALSE</t> of destinations, return FALSE.</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>Let BASEURL be the URL of the dictionary request.</t> <t>Let BASEURL be the URL of the dictionary request.</t>
</li> </li>
<li> <li>
<t>Let URL represent the URL of the outbound request being checked .</t> <t>Let URL represent the URL of the outbound request being checked .</t>
</li> </li>
<li> <li>
<t>If the Origin of BASEURL and the Origin of URL are not the same , return <t>If the Origin of BASEURL and the Origin of URL are not the same , return
FALSE (see <xref section="4.3.1" sectionFormat="of" target="HTTP"/>).</t> FALSE (see <xref section="4.3.1" sectionFormat="of" target="RFC9110"/>).</t>
</li> </li>
<li> <li>
<t>Let MATCH be the value of "match" for the given dictionary.</t> <t>Let MATCH be the value of "match" for the given dictionary.</t>
</li> </li>
<li> <li>
<!--[rfced] Is "by running the steps to create a URL pattern" needed
in this sentence or may it be rephrased as follows for conciseness?
Original:
6. Let PATTERN be a URL pattern created by running the steps to
create a URL pattern by setting input=MATCH, and baseURL=URL
(see Part create of [URLPATTERN]).
Perhaps:
6. Let PATTERN be a URL pattern; the URL pattern is created by
setting input=MATCH and baseURL=URL (see Part create of
[URLPATTERN]).
-->
<t>Let PATTERN be a URL pattern created by running the steps to cr eate a <t>Let PATTERN be a URL pattern created by running the steps to cr eate a
URL pattern by setting input=MATCH, and baseURL=URL (see URL pattern by setting input=MATCH and baseURL=URL (see
<xref target="URLPATTERN" section="create" relative="#url-pattern-create"/>).</t > <xref target="URLPATTERN" section="create" relative="#url-pattern-create"/>).</t >
</li> </li>
<li> <li>
<t>Return the result of running the "match" steps on PATTERN with input=URL <t>Return the result of running the "match" steps on PATTERN with input=URL,
which will check for a match between the request URL and the supplied "match" which will check for a match between the request URL and the supplied "match"
string (see <xref target="URLPATTERN" section="match" relative="#url-pattern-mat ch"/>).</t> string (see <xref target="URLPATTERN" section="match" relative="#url-pattern-mat ch"/>).</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="multiple-matching-dictionaries"> <section anchor="multiple-matching-dictionaries">
<name>Multiple matching dictionaries</name> <name>Multiple Matching Dictionaries</name>
<t>When there are multiple dictionaries that match a given request URL , the client <t>When there are multiple dictionaries that match a given request URL , the client
<bcp14>MUST</bcp14> pick a single dictionary using the following rules:</t> <bcp14>MUST</bcp14> pick a single dictionary using the following rules:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>For clients that support request destinations, a dictionary tha t specifies <t>For clients that support request destinations, a dictionary tha t specifies
and matches a "match-dest" takes precedence over a match that does not use a and matches a "match-dest" takes precedence over a match that does not use a
destination.</t> destination.</t>
</li> </li>
<li> <li>
<t>Given equivalent destination precedence, the dictionary with th e longest <t>Given equivalent destination precedence, the dictionary with th e longest
"match" takes precedence.</t> "match" takes precedence.</t>
</li> </li>
<li> <li>
<t>Given equivalent destination and match length precedence, the m ost recently <t>Given equivalent destination and match length precedence, the m ost recently
fetched dictionary takes precedence.</t> fetched dictionary takes precedence.</t>
</li> </li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="dictionary-id"> <section anchor="dictionary-id">
<name>Dictionary-ID</name> <name>Dictionary-ID</name>
<t>When a HTTP client makes a request for a resource for which it has an
<t>When an HTTP client makes a request for a resource for which it has a
n
appropriate dictionary and the dictionary was stored with a server-provided appropriate dictionary and the dictionary was stored with a server-provided
"id" in the Use-As-Dictionary response then the client <bcp14>MUST</bcp14> echo the stored "id" in the Use-As-Dictionary response, the client <bcp14>MUST</bcp14> echo the stored
"id" in a "Dictionary-ID" request header.</t> "id" in a "Dictionary-ID" request header.</t>
<t>The "Dictionary-ID" request header is a Structured Field <xref target ="STRUCTURED-FIELDS"/> <t>The "Dictionary-ID" request header is a Structured Field <xref target ="RFC9651"/>
String of up to 1024 characters (after any decoding) and <bcp14>MUST</bcp14> be identical to String of up to 1024 characters (after any decoding) and <bcp14>MUST</bcp14> be identical to
the server-provided "id".</t> the server-provided "id".</t>
<t>For example, given a HTTP response that set a dictionary ID:</t> <t>For example, given an HTTP response that set a dictionary ID:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Use-As-Dictionary: match="/app/*/main.js", id="dictionary-12345" Use-As-Dictionary: match="/app/*/main.js", id="dictionary-12345"
]]></sourcecode> ]]></sourcecode>
<t>A future request that matches the given dictionary will include both the hash <t>A future request that matches the given dictionary will include both the hash
and the ID:</t> and the ID:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=: Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Dictionary-ID: "dictionary-12345" Dictionary-ID: "dictionary-12345"
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="the-compression-dictionary-link-relation-type"> <section anchor="the-compression-dictionary-link-relation-type">
<name>The 'compression-dictionary' Link Relation Type</name> <name>The "compression-dictionary" Link Relation Type</name>
<t>This specification defines the 'compression-dictionary' link relation t <t>This specification defines the "compression-dictionary" link relation t
ype ype
<xref target="WEB-LINKING"/> that provides a mechanism for a HTTP response to pr <xref target="RFC8288"/> that provides a mechanism for an HTTP response to provi
ovide a URL de a URL
for a compression dictionary that is related to, but not directly used by the for a compression dictionary that is related to but not directly used by the
current HTTP response.</t> current HTTP response.</t>
<t>The 'compression-dictionary' link relation type indicates that fetching and <t>The "compression-dictionary" link relation type indicates that fetching and
caching the specified resource is likely to be beneficial for future requests. caching the specified resource is likely to be beneficial for future requests.
The response to some of those future requests are likely to be able to use The response to some of those future requests likely have the ability to use
the indicated resource as a compression dictionary.</t> the indicated resource as a compression dictionary.</t>
<t>Clients can fetch the provided resource at a time that they determine w ould <t>Clients can fetch the provided resource at a time that they determine w ould
be appropriate.</t> be appropriate.</t>
<!--[rfced] May we update this sentence for clarity? Should "caching
response header" be singular (option A) or plural (option B)?
Should "caching" contain quote marks for consistency or is it
correct as is?
Current:
The response to the fetch for the compression dictionary needs to
include a "Use-As-Dictionary" and caching response headers for it to
be usable as a compression dictionary.
Perhaps A:
The response to the fetch for the compression dictionary needs to
include a "Use-As-Dictionary" response header and a caching response
header for it to be usable as a compression dictionary.
Perhaps B:
The response to the fetch for the compression dictionary needs to
include a "Use-As-Dictionary" response header and caching response
headers for it to be usable as a compression dictionary.
-->
<t>The response to the fetch for the compression dictionary needs to inclu de a <t>The response to the fetch for the compression dictionary needs to inclu de a
"Use-As-Dictionary" and caching response headers for it to be usable as a "Use-As-Dictionary" and caching response headers for it to be usable as a
compression dictionary. The link relation only provides the mechanism for compression dictionary. The link relation only provides the mechanism for
triggering the fetch of the dictionary.</t> triggering the fetch of the dictionary.</t>
<t>The following example shows a link to a resource at <t>The following example shows a link to a resource at
https://example.org/dict.dat that is expected to produce a compression https://example.org/dict.dat that is expected to produce a compression
dictionary:</t> dictionary:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Link: <https://example.org/dict.dat>; rel="compression-dictionary" Link: <https://example.org/dict.dat>; rel="compression-dictionary"
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="dictionary-compressed-brotli"> <section anchor="dictionary-compressed-brotli">
<name>Dictionary-Compressed Brotli</name> <name>Dictionary-Compressed Brotli</name>
<t>The "dcb" content encoding identifies a resource that is a <t>The "dcb" content encoding identifies a resource that is a
"Dictionary-Compressed Brotli" stream.</t> "Dictionary-Compressed Brotli" stream.</t>
<t>A "Dictionary-Compressed Brotli" stream has a fixed header that is foll owed by <t>A "Dictionary-Compressed Brotli" stream has a fixed header that is foll owed by
a Shared Brotli <xref target="SHARED-BROTLI"/> stream. The header consists of a fixed 4-byte a Shared Brotli <xref target="RFC9841"/> stream. The header consists of a fixed 4-byte
sequence and a 32-byte hash of the external dictionary that was used. The sequence and a 32-byte hash of the external dictionary that was used. The
Shared Brotli stream is created using the referenced external dictionary and a Shared Brotli stream is created using the referenced external dictionary and a
compression window that is at most 16 MB in size.</t> compression window that is at most 16 MB in size.</t>
<!-- [rfced] The following sentence points to a section (Section 9.2) that
doesn't exist. The term "prefix dictionary" is used in Section 8.2. May
we update as follows?
Original:
The dictionary used for the "dcb" content encoding is a "raw"
dictionary type as defined in Section 2.1.4 and is treated as a
prefix dictionary as defined in Section 9.2 of [SHARED-BROTLI].
Perhaps:
The dictionary used for the "dcb" content encoding is a "raw"
dictionary type as defined in Section 2.1.4 and is treated as a
prefix dictionary as defined in Section 8.2 of [SHARED-BROTLI].
-->
<t>The dictionary used for the "dcb" content encoding is a "raw" dictionar y type <t>The dictionary used for the "dcb" content encoding is a "raw" dictionar y type
as defined in <xref target="type"/> and is treated as a prefix dictionary as def ined in as defined in <xref target="type"/> and is treated as a prefix dictionary as def ined in
section 9.2 of the Shared Brotli Compressed Data Format draft. <xref target="RFC9841" sectionFormat="of" section="9.2"/>.</t>
<xref target="SHARED-BROTLI"/></t>
<t>The 36-byte fixed header is as follows:</t> <t>The 36-byte fixed header is as follows:</t>
<dl> <dl>
<dt>Magic_Number:</dt> <dt>Magic_Number:</dt>
<dd> <dd>
<t>4 fixed bytes: 0xff, 0x44, 0x43, 0x42.</t> <t>4 fixed bytes -- 0xff, 0x44, 0x43, 0x42.</t>
</dd> </dd>
<dt>SHA_256_Hash:</dt> <dt>SHA_256_Hash:</dt>
<dd> <dd>
<t>32 bytes. SHA-256 hash digest of the dictionary <xref target="SHA-2 56"/>.</t> <t>32 bytes. SHA-256 hash digest of the dictionary <xref target="RFC62 34"/>.</t>
</dd> </dd>
</dl> </dl>
<t>Clients that announce support for dcb content encoding <bcp14>MUST</bcp 14> be able to <t>Clients that announce support for dcb content encoding <bcp14>MUST</bcp 14> be able to
decompress resources that were compressed with a window size of up to 16 MB.</t> decompress resources that were compressed with a window size of up to 16 MB.</t>
<t>With Brotli compression, the full dictionary is available during compre ssion <t>With Brotli compression, the full dictionary is available during compre ssion
and decompression independent of the compression window, allowing for and decompression independent of the compression window, allowing for
delta-compression of resources larger than the compression window.</t> delta-compression of resources larger than the compression window.</t>
</section> </section>
<section anchor="dictionary-compressed-zstandard"> <section anchor="dictionary-compressed-zstandard">
<name>Dictionary-Compressed Zstandard</name> <name>Dictionary-Compressed Zstandard</name>
<t>The "dcz" content encoding identifies a resource that is a <t>The "dcz" content encoding identifies a resource that is a
"Dictionary-Compressed Zstandard" stream.</t> "Dictionary-Compressed Zstandard" stream.</t>
<t>A "Dictionary-Compressed Zstandard" stream is a binary stream that star ts with <t>A "Dictionary-Compressed Zstandard" stream is a binary stream that star ts with
a 40-byte fixed header and is followed by a Zstandard <xref target="RFC8878"/> s tream of the a 40-byte fixed header and is followed by a Zstandard <xref target="RFC8878"/> s tream of the
response that has been compressed with an external dictionary.</t> response that has been compressed with an external dictionary.</t>
<t>The dictionary used for the "dcz" content encoding is a "raw" dictionar y type <t>The dictionary used for the "dcz" content encoding is a "raw" dictionar y type
as defined in <xref target="type"/> and is treated as a raw dictionary as per se as defined in <xref target="type"/> and is treated as a raw dictionary as per <x
ction 5 of ref target="RFC8878" sectionFormat="of" section="5"/>.</t>
RFC 8878.</t>
<t>The 40-byte header consists of a fixed 8-byte sequence followed by the <t>The 40-byte header consists of a fixed 8-byte sequence followed by the
32-byte SHA-256 hash of the external dictionary that was used to compress the 32-byte SHA-256 hash of the external dictionary that was used to compress the
resource:</t> resource:</t>
<dl> <dl>
<dt>Magic_Number:</dt> <dt>Magic_Number:</dt>
<dd> <dd>
<t>8 fixed bytes: 0x5e, 0x2a, 0x4d, 0x18, 0x20, 0x00, 0x00, 0x00.</t> <t>8 fixed bytes -- 0x5e, 0x2a, 0x4d, 0x18, 0x20, 0x00, 0x00, 0x00.</t >
</dd> </dd>
<dt>SHA_256_Hash:</dt> <dt>SHA_256_Hash:</dt>
<dd> <dd>
<t>32 bytes. SHA-256 hash digest of the dictionary <xref target="SHA-2 56"/>.</t> <t>32 bytes. SHA-256 hash digest of the dictionary <xref target="RFC62 34"/>.</t>
</dd> </dd>
</dl> </dl>
<t>The 40-byte header is a Zstandard skippable frame (little-endian 0x184D 2A5E) <t>The 40-byte header is a Zstandard skippable frame (little-endian 0x184D 2A5E)
with a 32-byte length (little-endian 0x00000020) that is compatible with with a 32-byte length (little-endian 0x00000020) that is compatible with
existing Zstandard decoders.</t> existing Zstandard decoders.</t>
<t>Clients that announce support for dcz content encoding <bcp14>MUST</bcp 14> be able to <t>Clients that announce support for dcz content encoding <bcp14>MUST</bcp 14> be able to
decompress resources that were compressed with a window size of at least 8 MB decompress resources that were compressed with a window size of at least 8 MB
or 1.25 times the size of the dictionary, which ever is greater, up to a or 1.25 times the size of the dictionary, whichever is greater, up to a
maximum of 128 MB.</t> maximum of 128 MB.</t>
<t>The window size used will be encoded in the content (currently, this ca n be <t>The window size used will be encoded in the content (currently, this ca n be
expressed in powers of two only) and it <bcp14>MUST</bcp14> be lower than this l imit. An expressed in powers of two only) and it <bcp14>MUST</bcp14> be lower than this l imit. An
implementation <bcp14>MAY</bcp14> treat a window size that exceeds the limit as a decoding implementation <bcp14>MAY</bcp14> treat a window size that exceeds the limit as a decoding
error.</t> error.</t>
<t>With Zstandard compression, the full dictionary is available during com pression <t>With Zstandard compression, the full dictionary is available during com pression
and decompression until the size of the input exceeds the compression window. and decompression until the size of the input exceeds the compression window.
Beyond that point the dictionary becomes unavailable. Using a compression Beyond that point, the dictionary becomes unavailable. Using a compression
window that is 1.25 times the size of the dictionary allows for full delta window that is 1.25 times the size of the dictionary allows for full delta
compression of resources that have grown by 25% between releases while still compression of resources that have grown by 25% between releases while still
giving the client control over the memory it will need to allocate for a given giving the client control over the memory it will need to allocate for a given
response.</t> response.</t>
</section> </section>
<section anchor="negotiating-the-content-encoding"> <section anchor="negotiating-the-content-encoding">
<name>Negotiating the content encoding</name> <name>Negotiating the Content Encoding</name>
<!-- [rfced] The phrase "available for use compressing the response..." is
difficult to parse. Please let us know if option A or B is preferred.
Original:
When a compression dictionary is available for use compressing the
response to a given request, the encoding to be used is negotiated
through the regular mechanism for negotiating content encoding in
HTTP through the "Accept-Encoding" request header and "Content-
Encoding" response header.
Perhaps A (removing "for use"):
When a compression dictionary is available to compress the
response to a given request, the encoding to be used is negotiated
through the regular mechanism for negotiating content encoding in
HTTP through the "Accept-Encoding" request header and "Content-
Encoding" response header.
Or
Perhaps B (adding "to" for readability):
When a compression dictionary is available for use to compress the
response to a given request, the encoding to be used is negotiated
through the regular mechanism for negotiating content encoding in
HTTP through the "Accept-Encoding" request header and "Content-
Encoding" response header.
-->
<t>When a compression dictionary is available for use compressing the resp onse to <t>When a compression dictionary is available for use compressing the resp onse to
a given request, the encoding to be used is negotiated through the regular a given request, the encoding to be used is negotiated through the regular
mechanism for negotiating content encoding in HTTP through the "Accept-Encoding" mechanism for negotiating content encoding in HTTP through the "Accept-Encoding"
request header and "Content-Encoding" response header.</t> request header and "Content-Encoding" response header.</t>
<t>The dictionary to use is negotiated separately and advertised in the <t>The dictionary to use is negotiated separately and advertised in the
"Available-Dictionary" request header.</t> "Available-Dictionary" request header.</t>
<section anchor="accept-encoding"> <section anchor="accept-encoding">
<name>Accept-Encoding</name> <name>Accept-Encoding</name>
<t>When a dictionary is available for use on a given request, and the cl <t>When a dictionary is available for use on a given request and the cli
ient ent
chooses to make dictionary-based content-encoding available, the client adds chooses to make dictionary-based content encoding available, the client adds
the dictionary-aware content encodings that it supports to the the dictionary-aware content encodings that it supports to the
"Accept-Encoding" request header. e.g.:</t> "Accept-Encoding" request header. For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz
]]></sourcecode> ]]></sourcecode>
<t>When a client does not have a stored dictionary that matches the requ est, or <t>When a client does not have a stored dictionary that matches the requ est or
chooses not to use one for the request, the client <bcp14>MUST NOT</bcp14> send its chooses not to use one for the request, the client <bcp14>MUST NOT</bcp14> send its
dictionary-aware content-encodings in the "Accept-Encoding" request header.</t> dictionary-aware content encodings in the "Accept-Encoding" request header.</t>
</section> </section>
<section anchor="content-encoding"> <section anchor="content-encoding">
<name>Content-Encoding</name> <name>Content-Encoding</name>
<t>If a server supports one of the dictionary encodings advertised by th e client <t>If a server supports one of the dictionary encodings advertised by th e client
and chooses to compress the content of the response using the dictionary that and chooses to compress the content of the response using the dictionary that
the client has advertised then it sets the "Content-Encoding" response header the client has advertised, then it sets the "Content-Encoding" response header
to the appropriate value for the algorithm selected. e.g.:</t> to the appropriate value for the algorithm selected. For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Content-Encoding: dcb Content-Encoding: dcb
]]></sourcecode> ]]></sourcecode>
<t>If the response is cacheable, it <bcp14>MUST</bcp14> include a "Vary" header to prevent caches <t>If the response is cacheable, it <bcp14>MUST</bcp14> include a "Vary" header to prevent caches from
serving dictionary-compressed resources to clients that don't support them or serving dictionary-compressed resources to clients that don't support them or
serving the response compressed with the wrong dictionary:</t> serving the response compressed with the wrong dictionary. For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Vary: accept-encoding, available-dictionary Vary: accept-encoding, available-dictionary
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="content-encoding-1"> <section anchor="content-encoding-1">
<name>Content Encoding</name> <name>Content Encoding Registration</name>
<t>IANA is asked to enter the following into the "HTTP Content Coding Re <t>IANA has added the following entries to the "HTTP Content Coding
gistry" Registry" maintained at <eref
registry maintained at target="https://www.iana.org/assignments/http-parameters/"
&lt;<eref target="https://www.iana.org/assignments/http-parameters/http-paramete brackets="angle"/>:</t>
rs.xhtml"/>&gt;:</t>
<ul spacing="normal"> <dl spacing="compact" newline="false">
<li> <dt>Name:</dt><dd>dcb</dd>
<t>Name: dcb</t> <dt>Description:</dt><dd>"Dictionary-Compressed Brotli" data format.</
</li> dd>
<li> <dt>Reference:</dt><dd>RFC 9842, <xref target="dictionary-compressed-b
<t>Description: "Dictionary-Compressed Brotli" data format.</t> rotli"/></dd>
</li> </dl>
<li>
<t>Reference: This document</t> <dl spacing="compact" newline="false">
</li> <dt>Name:</dt><dd>dcz</dd>
<li> <dt>Description:</dt><dd>"Dictionary-Compressed Zstandard" data format
<t>Notes: <xref target="dictionary-compressed-brotli"/></t> .</dd>
</li> <dt>Reference:</dt><dd>RFC 9842, <xref target="dictionary-compressed-z
</ul> standard"/></dd>
<t>IANA is asked to enter the following into the "HTTP Content Coding Re </dl>
gistry"
registry maintained at
&lt;<eref target="https://www.iana.org/assignments/http-parameters/http-paramete
rs.xhtml"/>&gt;:</t>
<ul spacing="normal">
<li>
<t>Name: dcz</t>
</li>
<li>
<t>Description: "Dictionary-Compressed Zstandard" data format.</t>
</li>
<li>
<t>Reference: This document</t>
</li>
<li>
<t>Notes: <xref target="dictionary-compressed-zstandard"/></t>
</li>
</ul>
</section> </section>
<section anchor="header-field-registration"> <section anchor="header-field-registration">
<name>Header Field Registration</name> <name>Header Field Registration</name>
<t>IANA is asked to update the <t>IANA has added the following entries to the
"Hypertext Transfer Protocol (HTTP) Field Name Registry" registry maintained at "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at
&lt;<eref target="https://www.iana.org/assignments/http-fields/http-fields.xhtml <eref brackets="angle" target="https://www.iana.org/assignments/http-fields/"/>:
"/>&gt; according </t>
to the table below:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Field Name</th> <th align="left">Field Name</th>
<th align="left">Status</th> <th align="left">Status</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Use-As-Dictionary</td> <td align="left">Use-As-Dictionary</td>
<td align="left">permanent</td> <td align="left">permanent</td>
<td align="left"> <td align="left">RFC 9842, <xref target="use-as-dictionary"/></td>
<xref target="use-as-dictionary"/> of this document</td>
</tr> </tr>
<tr> <tr>
<td align="left">Available-Dictionary</td> <td align="left">Available-Dictionary</td>
<td align="left">permanent</td> <td align="left">permanent</td>
<td align="left"> <td align="left">RFC 9842, <xref target="available-dictionary"/></
<xref target="available-dictionary"/> of this document</td> td>
</tr> </tr>
<tr> <tr>
<td align="left">Dictionary-ID</td> <td align="left">Dictionary-ID</td>
<td align="left">permanent</td> <td align="left">permanent</td>
<td align="left"> <td align="left">RFC 9842, <xref target="dictionary-id"/></td>
<xref target="dictionary-id"/> of this document</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="link-relation-registration"> <section anchor="link-relation-registration">
<name>Link Relation Registration</name> <name>Link Relation Registration</name>
<t>IANA is asked to update the "Link Relation Types" registry maintained <t>IANA has added the following entry to the "Link Relation Types" regis
at try
&lt;<eref target="https://www.iana.org/assignments/link-relations/link-relations maintained at <eref
.xhtml"/>&gt;:</t> target="https://www.iana.org/assignments/link-relations/"
<ul spacing="normal"> brackets="angle"/>:</t>
<li>
<t>Relation Name: compression-dictionary</t> <dl spacing="compact" newline="false">
</li> <dt>Relation Name:</dt><dd>compression-dictionary</dd>
<li> <dt>Description:</dt><dd>Refers to a compression dictionary used for c
<t>Description: Refers to a compression dictionary used for content ontent encoding.</dd>
encoding.</t> <dt>Reference:</dt><dd>RFC 9842, <xref target="the-compression-diction
</li> ary-link-relation-type"/></dd>
<li> </dl>
<t>Reference: This document, <xref target="the-compression-dictionar
y-link-relation-type"/></t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="compatibility-considerations"> <section anchor="compatibility-considerations">
<name>Compatibility Considerations</name> <name>Compatibility Considerations</name>
<t>It is not unusual for there to be devices on the network path that inte <t>It is not unusual for devices to be on the network path that intercept,
rcept, inspect, and process HTTP requests (web proxies, firewalls, intrusion detection
inspect and process HTTP requests (web proxies, firewalls, intrusion detection systems, etc.). To minimize the risk of these devices incorrectly processing
systems, etc). To minimize the risk of these devices incorrectly processing
dictionary-compressed responses, compression dictionary transport <bcp14>MUST</b cp14> only be dictionary-compressed responses, compression dictionary transport <bcp14>MUST</b cp14> only be
used in secure contexts (HTTPS).</t> used in secure contexts (HTTPS).</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations for Brotli <xref target="RFC7932"/>, Shared Brotli <t>The security considerations for Brotli <xref target="RFC7932"/>, Shared Brotli
<xref target="SHARED-BROTLI"/> and Zstandard <xref target="RFC8878"/> apply to t he <xref target="RFC9841"/>, and Zstandard <xref target="RFC8878"/> apply to the
dictionary-based versions of the respective algorithms.</t> dictionary-based versions of the respective algorithms.</t>
<section anchor="changing-content"> <section anchor="changing-content">
<name>Changing content</name> <name>Changing Content</name>
<t>The dictionary must be treated with the same security precautions as <t>The dictionary must be treated with the same security precautions as
the content, because a change to the dictionary can result in a the content because a change to the dictionary can result in a
change to the decompressed content.</t> change to the decompressed content.</t>
<t>The dictionary is validated using a SHA-256 hash of the content to ma ke sure <t>The dictionary is validated using an SHA-256 hash of the content to m ake sure
that the client and server are both using the same dictionary. The strength that the client and server are both using the same dictionary. The strength
of the SHA-256 hash algorithm isn't explicitly needed to counter attacks of the SHA-256 hash algorithm isn't explicitly needed to counter attacks
since the dictionary is being served from the same origin as the content. That since the dictionary is being served from the same origin as the content. That
said, if a weakness is discovered in SHA-256 and it is determined that the said, if a weakness is discovered in SHA-256 and it is determined that the
dictionary negotiation should use a different hash algorithm, the dictionary negotiation should use a different hash algorithm, the
"Use-As-Dictionary" response header can be extended to specify a different "Use-As-Dictionary" response header can be extended to specify a different
algorithm and the server would just ignore any "Available-Dictionary" requests algorithm and the server would just ignore any "Available-Dictionary" requests
that do not use the updated hash.</t> that do not use the updated hash.</t>
</section> </section>
<section anchor="reading-content"> <section anchor="reading-content">
<name>Reading content</name> <name>Reading Content</name>
<t>The compression attacks in <xref section="2.6" sectionFormat="of" tar get="RFC7457"/> show that it's a bad idea <t>The compression attacks in <xref section="2.6" sectionFormat="of" tar get="RFC7457"/> show that it's a bad idea
to compress data from mixed (e.g. public and private) sources -- the data to compress data from mixed (e.g., public and private) sources. The data
sources include not only the compressed data but also the dictionaries. For sources include not only the compressed data but also the dictionaries. For
example, if you compress secret cookies using a public-data-only dictionary, example, if secret cookies are compressed using a public-data-only dictionary,
you still leak information about the cookies.</t> information about the cookies is still leaked.</t>
<t>Not only can the dictionary reveal information about the compressed
data, but vice versa, data compressed with the dictionary can reveal <!-- [rfced] FYI: We rephrased the following sentence for clarity.
the contents of the dictionary when an adversary can control parts of
data to compress and see the compressed size. On the other hand, if Original:
Not only can the dictionary reveal information about the compressed
data, but vice versa, data compressed with the dictionary can reveal
the contents of the dictionary when an adversary can control parts of
data to compress and see the compressed size.
Current:
The dictionary can reveal information about the compressed data and
vice versa. That is, data compressed with the dictionary can reveal
contents of the dictionary when an adversary can control parts of
the data to compress and see the compressed size.
-->
<t>The dictionary can reveal information about the compressed
data and vice versa. That is, data compressed with the dictionary can reveal
contents of the dictionary when an adversary can control parts of
the data to compress and see the compressed size. On the other hand, if
the adversary can control the dictionary, the adversary can learn the adversary can control the dictionary, the adversary can learn
information about the compressed data.</t> information about the compressed data.</t>
</section> </section>
<section anchor="security-mitigations"> <section anchor="security-mitigations">
<name>Security Mitigations</name> <name>Security Mitigations</name>
<t>If any of the mitigations do not pass, the client <bcp14>MUST</bcp14> drop the response and <t>If any of the mitigations do not pass, the client <bcp14>MUST</bcp14> drop the response and
return an error.</t> return an error.</t>
<section anchor="cross-origin-protection"> <section anchor="cross-origin-protection">
<name>Cross-origin protection</name> <name>Cross-Origin Protection</name>
<t>To make sure that a dictionary can only impact content from the sam e origin <t>To make sure that a dictionary can only impact content from the sam e origin
where the dictionary was served, the URL Pattern used for matching a dictionary where the dictionary was served, the URL Pattern used for matching a dictionary
to requests (<xref target="match"/>) is guaranteed to be for the same origin tha t the to requests (<xref target="match"/>) is guaranteed to be for the same origin tha t the
dictionary is served from.</t> dictionary is served from.</t>
</section> </section>
<section anchor="response-readability"> <section anchor="response-readability">
<name>Response readability</name> <name>Response Readability</name>
<t>For clients, like web browsers, that provide additional protection against the <t>For clients, like web browsers, that provide additional protection against the
readability of the payload of a response and against user tracking, additional readability of the payload of a response and against user tracking, additional
protections <bcp14>MUST</bcp14> be taken to make sure that the use of dictionary -based protections <bcp14>MUST</bcp14> be taken to make sure that the use of dictionary -based
compression does not reveal information that would not otherwise be available.</ t> compression does not reveal information that would not otherwise be available.</ t>
<t>In these cases, dictionary compression <bcp14>MUST</bcp14> only be used when both the <t>In these cases, dictionary compression <bcp14>MUST</bcp14> only be used when both the
dictionary and the compressed response are fully readable by the client.</t> dictionary and the compressed response are fully readable by the client
.</t>
<!--[rfced] Please clarify the phrasing in this "either" sentence. Is
the intended meaning that the dictionary and compressed response
are same-origin or the response is cross-origin?
Original:
In browser terms, that means that both are either same-origin to the context
they are being fetched from or that the response is cross-origin and passes
the CORS check (see Part CORS check of [FETCH]).
Perhaps:
In browser terms, that means either the dictionary and compressed
response are same-origin to the context they are being fetched from or
the response is cross-origin and passes the Cross-Origin Resource
Sharing (CORS) check (see Part CORS check of [FETCH]).
-->
<t>In browser terms, that means that both are either same-origin to th e context <t>In browser terms, that means that both are either same-origin to th e context
they are being fetched from or that the response is cross-origin and passes they are being fetched from or that the response is cross-origin and passes
the CORS check (see <xref target="FETCH" section="CORS check" relative="#cors-ch eck"/>).</t> the Cross-Origin Resource Sharing (CORS) check (see <xref target="FETCH" section ="CORS check" relative="#cors-check"/>).</t>
</section> </section>
<section anchor="server-responsibility"> <section anchor="server-responsibility">
<name>Server Responsibility</name> <name>Server Responsibility</name>
<t>As with any usage of compressed content in a secure context, a pote ntial <t>As with any usage of compressed content in a secure context, a pote ntial
timing attack exists if the attacker can control any part of the dictionary, timing attack exists if the attacker can control any part of the dictionary
or if it can read the dictionary and control any part of the content being or if it can read the dictionary and control any part of the content being
compressed, while performing multiple requests that vary the dictionary or compressed while performing multiple requests that vary the dictionary or
injected content. Under such an attack, the changing size or processing time injected content. Under such an attack, the changing size or processing time
of the response reveals information about the content, which might be of the response reveals information about the content, which might be
sufficient to read the supposedly secure response.</t> sufficient to read the supposedly secure response.</t>
<t>In general, a server can mitigate such attacks by preventing variat ions per <t>In general, a server can mitigate such attacks by preventing variat ions per
request, as in preventing active use of multiple dictionaries for the same request, as in preventing active use of multiple dictionaries for the same
content, disabling compression when any portion of the content comes from content, disabling compression when any portion of the content comes from
uncontrolled sources, and securing access and control over the dictionary uncontrolled sources, and securing access and control over the dictionary
content in the same way as the response content. In addition, the following content in the same way as the response content. In addition, the following
requirements on a server are intended to disable dictionary-aware compression requirements on a server are intended to disable dictionary-aware compression
when the client provides CORS request header fields that indicate a when the client provides CORS request header fields that indicate a
cross-origin request context.</t> cross-origin request context.</t>
<t>The following algorithm will return FALSE for cross-origin requests where <t>The following algorithm will return FALSE for cross-origin requests where
precautions such as not using dictionary-based compression should be precautions such as not using dictionary-based compression should be
considered:</t> considered:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>If there is no "Sec-Fetch-Site" request header then return TRUE .</t> <t>If there is no "Sec-Fetch-Site" request header, return TRUE.</t >
</li> </li>
<li> <li>
<t>if the value of the "Sec-Fetch-Site" request header is "same-or igin" then <t>If the value of the "Sec-Fetch-Site" request header is "same-or igin",
return TRUE.</t> return TRUE.</t>
</li> </li>
<li> <li>
<t>If there is no "Sec-Fetch-Mode" request header then return TRUE .</t> <t>If there is no "Sec-Fetch-Mode" request header, return TRUE.</t >
</li> </li>
<li> <li>
<t>If the value of the "Sec-Fetch-Mode" request header is "navigat e" or <t>If the value of the "Sec-Fetch-Mode" request header is "navigat e" or
"same-origin" then return TRUE.</t> "same-origin", return TRUE.</t>
</li> </li>
<li> <li>
<t>If the value of the "Sec-Fetch-Mode" request header is "cors": <t>If the value of the "Sec-Fetch-Mode" request header is "cors":
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the response does not include an "Access-Control-Allow-O rigin" response header then return FALSE.</t> <t>If the response does not include an "Access-Control-Allow-O rigin" response header, return FALSE.</t>
</li> </li>
<li> <li>
<t>If the request does not include an "Origin" request header then return FALSE.</t> <t>If the request does not include an "Origin" request header, return FALSE.</t>
</li> </li>
<li> <li>
<t>If the value of the "Access-Control-Allow-Origin" response header is "*" then return TRUE.</t> <t>If the value of the "Access-Control-Allow-Origin" response header is "*", return TRUE.</t>
</li> </li>
<li> <li>
<t>If the value of the "Access-Control-Allow-Origin" response header matches the value of the "Origin" request header then return TRUE.</t> <t>If the value of the "Access-Control-Allow-Origin" response header matches the value of the "Origin" request header, return TRUE.</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>return FALSE.</t> <t>Return FALSE.</t>
</li> </li>
</ol> </ol>
</section> </section>
</section> </section>
</section> </section>
<section anchor="privacy-considerations"> <section anchor="privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>Since dictionaries are advertised in future requests using the hash of the <t>Since dictionaries are advertised in future requests using the hash of the
content of the dictionary, it is possible to abuse the dictionary to turn it content of the dictionary, it is possible to abuse the dictionary to turn it
into a tracking cookie.</t> into a tracking cookie.</t>
<t>To mitigate any additional tracking concerns, clients <bcp14>MUST</bcp1 4> treat dictionaries <t>To mitigate any additional tracking concerns, clients <bcp14>MUST</bcp1 4> treat dictionaries
in the same way that they treat cookies <xref target="RFC6265"/>. This includes in the same way that they treat cookies <xref target="RFC6265"/>.
partitioning <!-- [rfced] May we rephrase the following sentence to improve readability?
Original:
This includes partitioning the storage as cookies are partitioned as well
as clearing the dictionaries whenever cookies are cleared.
Perhaps:
This includes partitioning the storage (just as cookies are
partitioned), as well as clearing the dictionaries whenever cookies are
cleared.
-->
This includes partitioning
the storage as cookies are partitioned as well as clearing the dictionaries the storage as cookies are partitioned as well as clearing the dictionaries
whenever cookies are cleared.</t> whenever cookies are cleared.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC8792" to="FOLDING"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC9111" to="HTTP-CACHING"/>
<displayreference target="RFC6234" to="SHA-256"/>
<displayreference target="RFC9841" to="SHARED-BROTLI"/>
<displayreference target="RFC9651" to="STRUCTURED-FIELDS"/>
<displayreference target="RFC3986" to="URL"/>
<displayreference target="RFC8288" to="WEB-LINKING"/>
<!-- [rfced] We note that both symbolic citation tags and numeric
citation tags are used for normative RFCs throughout the
document. May we make this convention consistent by including a
symbolic tag for RFC 8878 (perhaps "[ZSTD]")?
-->
<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="FETCH" target="https://fetch.spec.whatwg.org/"> <reference anchor="FETCH" target="https://fetch.spec.whatwg.org/">
<front> <front>
<title>Fetch - Living Standard</title> <title>Fetch Standard</title>
<author> <author>
<organization>WHATWG</organization> <organization>WHATWG</organization>
</author> </author>
<date/> <date/>
</front> </front>
<refcontent>WHATWG Living Standard</refcontent>
<annotation>Commit snapshot: <eref brackets="angle" target="https://fe
tch.spec.whatwg.org/commit-snapshots/5a9680638ebfc2b3b7f4efb2bef0b579a2663951/"/
></annotation>
</reference> </reference>
<reference anchor="FOLDING">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87
<title>Handling Long Lines in Content of Internet-Drafts and RFCs</t 92.xml"/>
itle> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<author fullname="K. Watsen" initials="K." surname="Watsen"/> 10.xml"/>
<author fullname="E. Auerswald" initials="E." surname="Auerswald"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<author fullname="A. Farrel" initials="A." surname="Farrel"/> 11.xml"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.88
<date month="June" year="2020"/> 78.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
<t>This document defines two strategies for handling long lines in 34.xml"/>
width-bounded text content. One strategy, called the "single backslash" strateg
y, is based on the historical use of a single backslash ('\') character to indic <!-- [RFCYYY1]
ate where line-folding has occurred, with the continuation occurring with the fi draft-vandevenne-shared-brotli-format-15 companion doc RFC 9841,
rst character that is not a space character (' ') on the next line. The second s in AUTH48 as of 08/27/25.
trategy, called the "double backslash" strategy, extends the first strategy by a -->
dding a second backslash character to identify where the continuation begins and <reference anchor="RFC9841" target="https://www.rfc-editor.org/info/rfc9841">
is thereby able to handle cases not supported by the first strategy. Both strat <front>
egies use a self-describing header enabling automated reconstitution of the orig <title>Shared Brotli Compressed Data Format</title>
inal content.</t> <author initials="J." surname="Alakuijala" fullname="Jyrki Alakuijala">
</abstract> <organization>Google, Inc.</organization>
</front> </author>
<seriesInfo name="RFC" value="8792"/> <author initials="T." surname="Duong" fullname="Thai Duong">
<seriesInfo name="DOI" value="10.17487/RFC8792"/> <organization>Google, Inc.</organization>
</reference> </author>
<reference anchor="HTTP"> <author initials="E." surname="Kliuchnikov" fullname="Evgenii Kliuchnikov"
<front> >
<title>HTTP Semantics</title> <organization>Google, Inc.</organization>
<author fullname="R. Fielding" initials="R." role="editor" surname=" </author>
Fielding"/> <author initials="Z." surname="Szabadka" fullname="Zoltan Szabadka">
<author fullname="M. Nottingham" initials="M." role="editor" surname <organization>Google, Inc.</organization>
="Nottingham"/> </author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R <author initials="L." surname="Vandevenne" fullname="Lode Vandevenne">
eschke"/> <organization>Google, Inc.</organization>
<date month="June" year="2022"/> </author>
<abstract> <date month='August' year='2025'/>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati </front>
on-level protocol for distributed, collaborative, hypertext information systems. <seriesInfo name="RFC" value="9841"/>
This document describes the overall architecture of HTTP, establishes common te <seriesInfo name="DOI" value="10.17487/RFC9841"/>
rminology, and defines aspects of the protocol that are shared by all versions. </reference>
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.96
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7 51.xml"/>
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.39
</abstract> 86.xml"/>
</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="RFC8878">
<front>
<title>Zstandard Compression and the 'application/zstd' Media Type</
title>
<author fullname="Y. Collet" initials="Y." surname="Collet"/>
<author fullname="M. Kucherawy" initials="M." role="editor" surname=
"Kucherawy"/>
<date month="February" year="2021"/>
<abstract>
<t>Zstandard, or "zstd" (pronounced "zee standard"), is a lossless
data compression mechanism. This document describes the mechanism and registers
a media type, content encoding, and a structured syntax suffix to be used when
transporting zstd-compressed content via MIME.</t>
<t>Despite use of the word "standard" as part of Zstandard, reader
s are advised that this document is not an Internet Standards Track specificatio
n; it is being published for informational purposes only.</t>
<t>This document replaces and obsoletes RFC 8478.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8878"/>
<seriesInfo name="DOI" value="10.17487/RFC8878"/>
</reference>
<reference anchor="SHA-256">
<front>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</
title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="T. Hansen" initials="T." surname="Hansen"/>
<date month="May" year="2011"/>
<abstract>
<t>Federal Information Processing Standard, FIPS</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6234"/>
<seriesInfo name="DOI" value="10.17487/RFC6234"/>
</reference>
<reference anchor="SHARED-BROTLI" target="https://datatracker.ietf.org/d
oc/draft-vandevenne-shared-brotli-format/">
<front>
<title>Shared Brotli Compressed Data Format</title>
<author>
<organization/>
</author>
<date year="2022" month="September"/>
</front>
</reference>
<reference anchor="STRUCTURED-FIELDS" target="https://datatracker.ietf.o
rg/doc/draft-ietf-httpbis-sfbis/">
<front>
<title>Structured Field Values for HTTP</title>
<author>
<organization/>
</author>
<date year="2024" month="May"/>
</front>
</reference>
<reference anchor="URL">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="URLPATTERN" target="https://urlpattern.spec.whatwg.or g/"> <reference anchor="URLPATTERN" target="https://urlpattern.spec.whatwg.or g/">
<front> <front>
<title>URL Pattern - Living Standard</title> <title>URL Pattern Standard</title>
<author> <author>
<organization>WHATWG</organization> <organization>WHATWG</organization>
</author> </author>
<date/> <date/>
</front> </front>
<refcontent>WHATWG Living Standard</refcontent>
<annotation>Commit snapshot: <eref brackets="angle" target="https://ur
lpattern.spec.whatwg.org/commit-snapshots/696b4029d52e5854044bac6b72cdb198cb962e
d0/"/></annotation>
</reference> </reference>
<reference anchor="WEB-LINKING">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
<title>Web Linking</title> 88.xml"/>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
> 19.xml"/>
<date month="October" year="2017"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<abstract> 74.xml"/>
<t>This specification defines a model for the relationships betwee
n resources on the Web ("links") and the type of those relationships ("link rela
tion types").</t>
<t>It also defines the serialisation of such links in HTTP headers
with the Link header field.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8288"/>
<seriesInfo name="DOI" value="10.17487/RFC8288"/>
</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="RFC5861"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
<front> 61.xml"/>
<title>HTTP Cache-Control Extensions for Stale Content</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/ 65.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.74
<date month="May" year="2010"/> 57.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79
<t>This document defines two independent HTTP Cache-Control extens 32.xml"/>
ions that allow control over the use of stale responses by caches. This document
is not an Internet Standards Track specification; it is published for informati
onal purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5861"/>
<seriesInfo name="DOI" value="10.17487/RFC5861"/>
</reference>
<reference anchor="RFC6265">
<front>
<title>HTTP State Management Mechanism</title>
<author fullname="A. Barth" initials="A." surname="Barth"/>
<date month="April" year="2011"/>
<abstract>
<t>This document defines the HTTP Cookie and Set-Cookie header fie
lds. These header fields can be used by HTTP servers to store state (called cook
ies) at HTTP user agents, letting the servers maintain a stateful session over t
he mostly stateless HTTP protocol. Although cookies have many historical infelic
ities that degrade their security and privacy, the Cookie and Set-Cookie header
fields are widely used on the Internet. This document obsoletes RFC 2965. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6265"/>
<seriesInfo name="DOI" value="10.17487/RFC6265"/>
</reference>
<reference anchor="RFC7457">
<front>
<title>Summarizing Known Attacks on Transport Layer Security (TLS) a
nd Datagram TLS (DTLS)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="R. Holz" initials="R." surname="Holz"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<date month="February" year="2015"/>
<abstract>
<t>Over the last few years, there have been several serious attack
s on Transport Layer Security (TLS), including attacks on its most commonly used
ciphers and modes of operation. This document summarizes these attacks, with th
e goal of motivating generic and protocol-specific recommendations on the usage
of TLS and Datagram TLS (DTLS).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7457"/>
<seriesInfo name="DOI" value="10.17487/RFC7457"/>
</reference>
<reference anchor="RFC7932">
<front>
<title>Brotli Compressed Data Format</title>
<author fullname="J. Alakuijala" initials="J." surname="Alakuijala"/
>
<author fullname="Z. Szabadka" initials="Z." surname="Szabadka"/>
<date month="July" year="2016"/>
<abstract>
<t>This specification defines a lossless compressed data format th
at compresses data using a combination of the LZ77 algorithm and Huffman coding,
with efficiency comparable to the best currently available general-purpose comp
ression methods.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7932"/>
<seriesInfo name="DOI" value="10.17487/RFC7932"/>
</reference>
</references> </references>
</references> </references>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA9U9aXMbN5bf8SuwdE3FTpGUJR9RuHFmZEm2tZGPleS4MplU
CuwGyY6a3dw+RMuK57fsD9lPu39s3wGgge6mLB+ZqXFVFLHZAB4e3n1Ao9FI
VEmV6oncz5erQpdlkmfyIIkq+L8qLuVZobJylReViPMoU0t4My7UrBolupqN
FlW1miblKGoGj2I3eLT9rYhUped5cTmRZRULEeVZqbOyLieyKmotLibynlCF
VhO5d3Imynq6TGia6nIFSx0dnj0R67w4nxd5vZrIZ2dnr8S5voRH8UTIkfQW
ls3C+E25gGljOS3yKk3wwbuyUlmsirj1YqzTSvkTCXGhs1rD/NJfVkqG6Q2A
k2Rz+RS/g6eLHJGCmCgnW1v4//V8nBfzLfhuqZJ0Ih2qRuv5X9b38Ev4ThXR
ohmXJmVVjvnLrT34KrnQ5darepom0ZY/AU5b6FXeDJ0n1aKejmEHZnX630i/
rQDTsJ9yK1VTnZZb/ackePwI8F7rEb06kRteFaquFnmBqBnBf1ImGZzkq7F8
rnWmMnrERPJKVUUSnftfFDnSmY6TKi/oAWxVZck7hbNP5NM8n6daHh/v05ea
cbda0gR/mdO3uMlw7Z/G8o0G0L2lf8rVhffwA8ueLvJVMruUR1nkr3sJk4zX
OMlfSn6D1hZZXixh5AWRx5PDs/1nExpmuOiJrqIFENVxcoE0cmpIjl6JgRUm
cqbSUvMQVcx11ZzjDMeOy5WOxuuFqhoqAlpxaJd292YnQI/P9s7ePEVoXh4f
HL14OpEnT/Z3v/l2Bx4h4dLnb7e375rPo/29/Wf2PXi+Dc9xxO43uxMpb8m/
lg3Qp8/2RjsPHtKrD3fu3edHJ4cHo8cnL8+Oj4K9nzLHPSaOc/IEnhwoYLAn
hDgPETu78lSvKr2c6kLu3N3Z6UUKvAuUpKJzXYyRDQgnIIq2WApdAKga2DXT
I2b4ETP8aEbLIfZOz05e75+9RqCfHB0eH5yGQIMYiqoaAX+S6DSWP6q01qWE
8ZbtLcDb8rm6REjvfwqkgbwsZ/ATgXt9ckzIvfft7kP++Grv7Ozw5EUAJDxG
hqp0kX0ibdVFuuIJPoPA3hw+Hh0fvfjBEdnO7q4QSTbzeQKeP9h9uE2kBCCm
evRmkcDPE32h0gTh5Jce7jx8QC/t5/l5okt++s39B9/Q07PjU7lXVYBO+823
93boG6YvIUajkVTTElFeCXG2SEoJ2K6XOqsk7jGZwaxSyaWOFsDv5ZLO1NNO
U4XE6WuQJJPVQotnIOeLCuQna78Z0OcrWDSP8lTeRqK4M5aPL2VdJWnyDo+i
wsUrWCdL/qvWQxmlCUABi2exKHVxoYtSRioDuR3XkcY1ZJm80zKfgRaEFZYJ
HE2Mh6iGMtUqpklzmQBo+QV8A/AQkrNIC5jUTATaDT6sk7haSFSs9XKFexvL
EBmkCOIS/g86BmfGLQQKb6nh9GOCV+KKSQyYm9fwvzTJDDMg0PgZNnNJL9Yl
bcCfxyEXMb8GtcII5QVXBoVjPrplEsepFuIWSN6qyGE/Felegt2cX0QyGpad
ERjts6xL3A3AmswzhQi8usKV3r8H/IDNApZGKRTuilBQZCr1jp9mmNXI+gyf
G0Pf+GRRRgu9hLkqYBpZ1is0h8zi3Ylx67f1eD4eWkl4dWXIFwBDinAClr9B
wfv+/Z1xm4ZhX1GRTGE6h8IFkAbSUo2Ei1BmYFtViaJT9bZWl2puCWUOh070
BzYVUUMW5URfF42gc5uFx3hsFnKcoVEHvGPlFtW+JUXg6wYgQBsQRxsmIG6g
H/ilpA191YDlDRS3S60BN6eaBsvtHZyKT/YOwZQgCtQUrAWCVqWpRB5DW8e+
CvDcuiVfA43uK6QDsZddhudMHDnVTlbEyHHwmZCLZLPBuESMiZBwgOnBepPr
RQLK3zGQkmleITyzFFhvCsKiukTe1DAQVJWs1jkusYQd1wROSWcNNIbfAg4y
OaO5syq9nOB+bskfeZvy9WpeAC0I8docCgB6keR1aRGB6yrca14XIHJoPy3i
x5Ncg2wzIwTYWYDSsuFymoLMY2fgA2q8BZAwkSHhPIeAtxoO4lLAa3VKFAnc
j6xJjIx7kOUS3oAVG1aD7Wb2IBQYvRql3fRS+KhXaZ5pOE+wIIDf1HIFKlGI
v//971Kp8mIu9knayhv+OyV5LH6/6fvNv99h0NPDM7mlVqvxxfb4t/Jmg0Yf
++/73z8VPPy3c/eufPnDRw4CRhntlaPG8ZuA7wLm6KMB7vbr38pBz6DvZjVw
XoMNR20juX337g+PZUM13+Og7z4aE5+ICHEKPhkYT/AjBTlVyPEY6OefQyc7
N6YTuXcBrgfyYHAOk9Vfny6392ALO2pn9uTp/UeTYFAUgRU9OjRifSLn75LV
EPzeIXq88VDG0RR/vPMG/YMp8qNI0g3aZ83g7Qx28qFB33XEVXMIPnn+8Pgf
S5EgrcTVhO35R4OWFJeHLNUG71nI75NSsAgQ4mgG2gD1Zur2UHJ8w+gPaWz7
0liwSShiQZEklZGyqGqAbVHXFRosWzAH9CYLiXQRKmgFrjZ8ysvOgkOhZzPU
0xca5LtvR8CyS5nXldUTDqCxJO40krzk70Gjw3aEmR2cwhUyLujX58ekq8pk
CaxRwLpoO6ioyEvUaGVSabIIzMBzfclWLBs34JvIvVdHsPU0Lb+YBvkc2eBJ
hwQ817fjRbVMbzjso2n1U/n2E3VJM+w4yc4n8jsQWVtITt//O5x++mjQH1Qa
tPSJh5drFcqn8e8ncrB3bgj5Rw37J5xb8O/Dh9g77BqT4Gs8ncE//AC+hFr/
QsyLcmjnY5j345X7J6r3fxrJfZys+CQ1f62i944kkBufrOo/g1JDdR/q81Db
yxd5RV4vqF544QJeQDeWvWlQZxJTHaUcPH99ejYY8v/li5f0+8nhf74+Ojk8
wN9Pn+0dH7tfhHnj9NnL18cHzW/NyP2Xz58fvjjgwfBUBo/E4PneT/ANqtLB
y1dnRy9f7B0P2LrwYxTkxpLXnMDeCjiKipxnYYMXMY55vP/qf/97+z649P92
8mR/Z3v72/fvzYfd7W/uw4c12Ci8Wp6BHcEfwWq4FGC+adD7SUZefqRWSaVS
8DYVWkD5OpPoToMU+PpnxMwvoHWm0Wr7/vfmAW44eGhxFjwknHWfdAYzEnse
9SzjsBk8b2E6hHfvp+Czxbv38Ls/Y0BOjrZ3//y9aAeMamPtgcGUpvmajDBd
LJMsT/M5uPxFvpQ2pnIPzC5xddWJjcNZwHlySAT89Uuw/d5yWFAVJXFnI72G
GDyHZ0NxlGUgjY+TshrKs/zcnuXjS7DOTimCEelOfMuBS1sCmCkqhfHcSs8T
ikN4NHR1ZdIb7993ZgKCyM107f26iCDCwx9s/oMmuuXnOl94MSgTPQo1oBBv
0JhmU9YGaRVHgU44CjREq5Q0DBncKobfqqTUbEz7hjB+L4J4U39w0oWX8Nnr
k2MTIyJdzBPWYEaLJoxlgq4d6JuVOY5oQnYffA/DbaqTKNlAPd40FJvzoowD
AhnlDf0ygvOt8FMSg8AhSYMJ1sGYnSB6hyE0A3ku6090wW5B62KchC/hwnI0
2EuoVEQ7BKFBNa+N400ksknL2EBtOIWLx7qBcQ4rZXk7XFzoeY1ujH5rDeHS
TNfwrErneQGoW3KYk+OSNndi4oNyDg5XFu4S9y3ovXB7OMCBgzvtAcJGVW2g
v1RLLV4WyRxo6XYTib0/vjfeDoKxjE4vDCyPKjj4FHUwEEsmgUQOBUcbGTam
W+M/0rpP9o5PDzkiiSkYfm3lg28lufFfY3DetsfyWMM3e2f7z1D/IBiOPizB
2O0wtvxgtRmOiDKD8VdDWrHPCkQRboAhAwpX0hALZ1RoiohPYUydZcYDBnGm
VyUeIH8PJ+QPgpdLXZlY6aquHtF2WHhidgrefYTvIxmKkAyvJiUfCrhVNPUA
fSzKwj0a3KqLdGQWGZmvkXBhE0fOG69T8s19aAcLhWGSOVAGlz6UA7MDxKTd
O59sKfBoObpgzpoPsodnPGC7K4gNcMObI35zZN40WzhpKGvcJyCSko4tQVGF
mCTqIRMlSuvYCUjxYcHn8l5eTISsHcy2gTDBFYhcAY6XK11wIsbIedI1mO9I
h0wKTkAHLFAyu+Q0HKiXYYNPEVrFlK3pBt0NES1kK1VCmRL4ksWUF+5wowaY
EZ5sba3X67H5jipH4v/7H7Ci0zgvZgOwOes0xn3a5cGi2zjwT/v3/vR4vxmM
KMfMA2xdZVWL3+3MJvxChSpLEEKYr7rG4WwvQgZ2oyZIlfikwLrlIxRGJhsb
Bk0jX7IahevndfgtU+1htQaumWRkPjhJKkLSYWSYQ6PqkYA5jA1x0EwUcIdZ
yFuHWELsZVIvV9Ulw9WoWoMFon9eGW1oH0xDJDZfbXRFoLj6dscEzaN4+gqF
jEwqm29twEFy2Lj4hhODE8lXxinC8bGeKRBXJEiD2Y2tkMRmKjAlPstKaAoH
hDPj4MzBJ4NnffKABCqA5K0MM6NeJcMUYEeBp0TJK6U6mwPXpnk21wUnv97p
IncxWiuqaHSVs9wwYICyFINmI6Ojg4E7HLMp9Jv8oykp74/g9UUfkLaC4b72
92WeoVfl5mi+a+yhLrbsZiqjGpk08pWCRaVByPTSg/f6mVj/o2BBGVqDoLaj
zQDA17xWBQgdTfJOmNxy2dXrlIb1twintHAAW2MLBRXghEz0cYfCwiO9rWYY
kVLZJVArRzLuWB4CM26F0G1j6VC0UFixAvK8O+V1dI8bYMLnhQ3po8ls5iHr
+WPIn1w130YOSw5mSUpmMfCnnQ83ROgPEv+DQq0HOCUXavR6MzgJ58cLbdiD
yKE21UOE7TSfovCdgt8I7n0Nrv6UQSC8dksyjO0+phSJslRf6Ehj9WQIA1cK
EL6Y1RPfLM6wrgILHYYoxBy91aVuU04Psq87NsKNOSsT+Cnp0y200BfyVQE4
ewsyvDE+/LSLZl0amCV9uhOAPZzIr/72FXvT60KtVkidYEdg8ZSkesA+Dfs3
qlJlLbviMpytr8Era4Tyo9sD62kP7rDifUNa3EYJnNNDxG+dcitb2PZH08Oc
ANktK9o2HrZb1Zg+LH1u7nvk9KZKhTPVGbsmx4blh2AJRlWOlTmfjefr8+Rb
X28tYbLxb+XAR5RRf4Ad2jsrmkqhYCCc8Fi2nEhim6d2Lq5l6RPhJiBhQhCG
/pfqnIg/PAEXE8WPzInAAaSdMoyyFfmqwKIej9aHNm2oYkRPvxJp6SBhRJV9
ilVsWYyVXLql0CwTLtrSwukZGCCsa+4xv2XBm4DzUbGLIF5lKcP6RjCEi2Hh
RdIWLBIDJYMJyQyLmJstdCSHbzVRsBOVdDPyZkg2rGTGEDgsiqwKn+LLDRQ2
WORh3H7XmxYNaP7azMXF3aPDxz/snUTv3n2j356/+Kn863T3+J16Xvz4zX/c
c0mNxmD3dNEMDnSRwSrWX1tSuvus7WIRgdAWhl3/3FC11d0aMIOmDE4tfvbj
fb9I5AOMsrhSL6LEGHkRcERWjp7Ln00F6y93xh2IUYxZced4zwMHSxdB0liY
Gy8buKcjOgYwsuDcOWkd45/iQOvQGhuDAuNWwwT2snnBVY2ZeJGwIgcz8POc
Q09GGmBY1OlKw5I99ArSckxngWhJZmauaV5TVaEXJyOA2xGWYRiIFk1Qqx0c
MuKprKMIKAFLEyzsfmQoy0f0mCM/JogR1UWBm7DWrrW2eh0ydkt95FmjfK1K
69zFLHpDIuOq6K8p/nNwaGzabrjJnMjmmFMzCyYhYKJfe2fjQlsHuZvQ7JZ7
Gqyu4zkBHzRVwtZM1wGD8wvWNC+aSDE9wne5PWLW8vX86I6Ngz3eOz386OAZ
vuWsv/a4DnFNNR4O0Fd0rmM/dmVsAxhnocAtht/QU+AH3KU1KuxORBCn2mRf
jL9QiPFfPmJowm3XRA2dsELIAZV2y8RLDCYAItjoIP6nUzWcz+w+1dVa6yyw
HfyjdZ6HWc0y7/XRRgPZhn3yt++tnH+OZasrqy2DkmoyHd8Y79qU7y7t60Hp
t5ebsVLR244fOGEvY4VNUk6TB/XSFr9NaoAyPSwCO2Gb6+M1qlPX5UU6bITG
Uz1GmFVkSq7Qo4rJKMrRclO+PRGkFpTwliXqeUooQPUOrGPK2p1oaybuKHYn
hylWAqLJnmUbpA+v0kSgjK/eXnaZl+w1YpGyoDaswMXtWVMEdsHo6OCPtcQd
G/gYUs7YsOYgGdYjq8sERRY+nA2sWlEjoksdLYy1Tku4uYBAro1BWeP8+kBV
r1Uue61yG4oFodNEUWQTRemPvARxfwokRQqLHkXjgDg8UQQmNIOHhnVVq2WA
OUdXIT8dHXyWqwjGX/xo4LfN7ty7/8B4kHutNLAnYEyYpq15WMIaY1JOc8NH
6CQIS0b9EH8RQz84+InctK9bFIH7qr8k8CuqIATNkzIHn5kg18bOoOq6uVKc
q7BzUcDs6srrZcOah1aAP+wz6lBBbt9llW7ymxvaRdjrKhkCss6HclpXJDPZ
AUgv2W7ncKawZm2wqOGrj9ik87uNgiC5ZrwJESn+PUxMOckE4KbJOZb0sqM0
1RlgOkqAh3oqE8YEmo+eEgv1yLDDmuF2IQNqz2B64+wjFohBLeQeRNc05Lga
QG6yo33SxhyDN7Mg51IBoS3HQKHBVSOak1NYkuEJYYN3f3Okk2kRZ5r3n3ym
dVxyBISZUYk+L5Dql815tEJQnEdKKteaRJiijMIGXBBbhcRAUYag/CEgbwHy
dT7XhTM3aGvdkHm7TsFmFrEMi5NisCjVw3joFrYB1aYMqSkWJh3HqnKsod8C
CTJvSA4H6vC0vTRan+Ay9cbXrfWBGmQrlDzp5TUw25ZT0mxxNB10u+lctqL0
EWA3GGZuOjOTH6/VEnN58kZvmqjZLHkLXxmlahfjI+I+KtXqyqYoVtO/DaLP
rEx0Yyai0EtpQ1q8xv0RRuVFaaNj7E7f26HHfkBscycBGiwo58YSFxMhYGZb
AL71ixoD2DUqxL2TEygBPwB9xvm6wX7FJt72Q/n8MXelvbOMHVjcpoqnuuaY
yUSmfIe/PdQpqsl/UL0aPjSFZ9gd7CXBbPTb34M/WBj/RX473rFYvUlzPd/M
MRadQ+at3nvIhxUQDW7Ikgy6Fs/VPIl+fVFjV/5ETOR98zrlZCby7tvZbAg/
79+nn/fo5w7gElb8defBw1+fASXguHs7PGRs7xBgGokTNOZ7YgVeeNWT5xzX
yrK8RpqzLg71cUfT7ulYi88Gj9EeZER5jTNMi7rQXjeBtaAN4djmbGNwItkA
UG+8zliP2kyoC1sXwkigF1SrSbr6Ao3zRGHzeaxXOkM54norOzQ95Agmzoai
OyyCNgUizVZTvAXA5Jn75xtvFnpN46+Ve+++nNxzk99E9HVeZjacJoRp86id
VQHRd/9uD8G7SjcnJGGq3pZsO7MJ9IdOAMrfKQYsOkTU20v1YWnTi9wvIm1g
fEvUYFbQypgHmISjFCFs2oBpEXeNPtjlN5w+8PGJ2LKaIeD+m2oICn9ZzjW4
J8LqEVC7bQH1QKNQ2lEkmmL8ub1LT+7iz7vBzy8uuHqwR4fYEFh5nqxWnNcu
MNN5O02qClwu4PwEaAehvX+ws/fg8I7N8lhU2kqD9oC79G/n7h3Hdog7sP1s
g7xwNz80YJCrzEUINxG27/54YQsvploBjndB3ApYdXu884CMdTZa3Y0ZizBH
yREUfcGonhPlF0Mju5VYqrfJsiYu3t7ZZUmOp+SvXjNUIMG9mrfEykze923j
lqWU20hK209pqmh5wApYoOB6k3VOhre5sKAp7UEucSKZ/KxlUo3lXiYSNFox
BcZm+/O9n0xZVYgqQql+G7FzQdY+zGBqLkwAROiiyAurs5pT/wPUVg3iP+0c
EEV9Ayj7dM9jfZlTRAK97zwxSQEPnCkuBedfZ02+UtorD3y4WhbfjUiHVWlp
PFoqTgNtKjZqUyP3LzRWrq4pFr/z4E8uco0Vj3SFwxrvuwHlAfQk5nxXjxdd
Q3oq8pQjqeyMLXPEvKmbRqeRKBeAo6w5BxcoyuN0EKntF97lHz6lWg51IckN
7mlw1nyfindMzvZ2jq9oBbSZgpw88G7PwPRSc0lItSjyem56Fbj2XIQBFv8a
k64SzDgS4k8zaLXFdUrZqJ2g3Vo22NABEdZoIhbCDZR6pbA4NzW+hu3pcJXE
N0ramyqOEPANSeTuuWAcu41+G80z+YRokefUBJNT4LnvqiPGh0OtWyYo6FRx
XIqQVUZqzd3m4dmUrqTA5V45PiI6B9RGhsQrcnqDkP0Nj2DsYPisr/PRlNoY
Wuc9uKwE8auygfK2weHHUR1awa62qKT0YW4OoKmuCBjAj5pjzRjVcyRVKTah
b9Sgz+iYD2KLSKdNzqbqzZTTuBNAQLuyrlnTI9+g+pJku0dDvgHmTr7VzO85
6S3UCg81FKtoVq1MsWupK578w4xqq4r87EhY8NIUGJQghzGYtJnEeltOmYqO
WvsjPQ8kwkxi1biL58nBj8TpNgKT0z08JOZxVEm3f4WXM/ktq55uydtF2NlX
TU6vorsUCjdbAGLbsMIv10UeLNqHhR8puq+Y8ix5DGVfla+Njh3tvdhDMqTC
HE4t+pQpPcrENym2cM7qTGN/aCudCQqfj3VAAt7Oss/C6YSuruIyZf4Nr9N0
1XqV+O7nX27bkB92JYA1rCjmp0q8dggtqZKvwkTxvcQwb+fz+C02DN/5HhA0
ki/4elOghZE8oFJYqrmZfCgkh/e2mRrXMQw9seGqSXgRG66Qk5NyddVLD+bu
QozX/Evj790N8ef59V8Mhe6W1/fcXv2MOZMTjAYlpsOzg+N6ZVrsQH99+A5A
MyduusG1/Gxcz3DW4HeLY+TVvCD+MufO9dFTDfQAB7Ch6//3Db/fpPnd26LX
3o73OlZ1yb+3/7mj6+vd//IQdvPaBBUc3lJlyA2/A6mA/h6pMmhbcNfOuIJl
ufmehs6E/a0Q3TlxwiAh2uAwnNAj5iTeAN0fhEPkkjDdemM2kYNunrb8PB7A
LNLIpq7aHwNp41ZlsbPhxuKWJCLq5D6iTW6RC8y1rd3rBNMQQ3ALveki7GAb
I47VoULdN4Eauhuwo1mPKluoV2d0u561dtytC7G+SNB8MKXzGbiieXHulZnT
tQyo4YciyTDRW9lLPrHasnV/4e21nuJXbxO8z2+WFHqNFycNcZaiZjyB1Kdd
ifKyrPQSvtRVdGcsz8DpSLJkyREKME+S8txYi2UDJxhOeWFS3gYGFGcbrSO+
MWq4MbVuLyf3yqlNizCleXRUW7P7Le4Pt3tK5V54EUJd9CH9jApEzJdR8CWh
v3up5zBMznTTL+E9mkGIGQxazoJXQa+gcdj8Sy2tzccFw429WxrnAK9h9Pzn
jme7rKmm0oWGna1I/RZux1jkpGpTMstuoJlxiNEYRVVe5tJHmwz3VuFbbqlK
kBrWWi9q73jNtF0fHGi+6cCyl472xZEtg1qHt4TTFu6eBevNZrF1kdAHo3qY
xmtptbpxGhTj/hhqFTb35q/tt+ejja7frtIkSpCiMXRjg9c12WvK3GAM60Xt
TiLcJ9e4mjJ0qsx2QHFfi+1yscgC+ECSlirBRiX0/tZanVMJPQqjpIwwrMTU
b6E28UdqzzKVDrErf/D7U/27W8sFda7wacfJjKRe1cLAkE2lnpKGdiO1ueGT
byJmFNnuIW96r0rclX3yyXHb8G9IwqApsCUPy72uD7uY+3pNO6vt5GLlRW2Z
C+acE3PfcsA4wf2jfIicZ3Gd1uOHSIbmympMFi1c/LH6itJTKsbsmBK+L812
Lh70krIWdFOwXNE1/0YyJxcA4B1pPcPRiOkGBgr7zPqfuDESen6A1VwkTTVG
dDNKQHZY1o/pYuEq3YCMLvO6ARFEQaExTknXcjsGZBhHOPWI1vRi8AInoIAn
hvDPpbsSHLE3xUsAGUCaEbD+wsIdmcRkUDR+oVW6cQq7R8GXZeMmUbWQqITP
tPM+j7gjo3AVX7z1dIlyP629xaW0Y20Ed0W5xnxGoAQRE5Y5un0sVHYgX/KW
c9TjQIbUcjgjSPqXaec7um8CzotMfAhjhBsmeaf8nidVMnfmxoy4yqBh2Xxl
eWgFhlo35hUX+SqMSGCBmWkawGyoSUXQzZZ4b+PIiDa8ENwYE9hn4kS4SUS1
j4wIJgF7Kaqc5O8TmWLNBlJPtSzJWd7B9de3+IsLuirTmkhXV/QSNiBitsn2
G9uOoqCF2uyzT9YmpS/1DXZOLAJBRceKjcKgQX9IZXMSzbRpka9hBjqPpnYR
Y7cJrZF66JVqjjd4ViaV6ua2R71Sl2kO0speGe1O0Q0EDBWS/rgBx4jcKqJZ
pWwavhX2FVedIyX5y7fGt02dsJzNBm97ZAEnFEkdkPRDLlrj/UpTHfS0HWXG
9KRrtYcBMXlL+XajSQMiz9uqWf/IXLS9a6GSZYEppEtzdOiVtzrbASBzZnRL
lT24pVaZifnRojiT6WFDGrK8YgwoY8qitLhkc4YMCFuyTuyQFw22gzimz3t8
pVdZajbx9l+enJqmjI2XUzTvBA0VYNCXI37sOin4ikVLz4ml5L3SlkjY6+C9
vx/QWIRcZh4a79jBsMrx2wTFNvgZdNEKKmb+uwYl6jESjfTQ2BxWhnLvbdGT
vx9iphmGmk5XPL5OmjCLN05kQaZzEM1ehiYLaP5wA0Lr+kWcMKFjuuCIebAi
qOck+41LIp3l9xp71LFPjmpMeJtGGlvbn/OchedaURJUtKP2zFflRiVr7H3O
rC+T+QI3KMp6hjXAxuJ2mKIgNWyZWlkjLvR1WUqg+rnO8Ori1sVoRr1osyFj
Yk0vbQCd7+UoEqOBAI+iyXuRLea9qNgnMrKlvzEnuNrKbRFMZuDWVpbb6n0A
BnzLxLvr3pw2J6WR20SdGdJIUcGzfTY0BkDE+XNFnY0BGbnkr6dmPOp3GmSt
Lq0H4MX7DUEcZU4Qt9stvX7aklOHnguEMQFrhfP+e1N9XnK91SDiaolJJLQv
EaGYpY0+cB03OoK+9LFDDHNfcwWa3y3adIP2TYZ5d9D7wndgmbZse1IrD9P9
8y/G6ZkSfZjmY7/htODEcC4HYECN6PKf0WnCjXQBDirvUiy+pgrmMPIp6PP8
0ESw3MBTAwOaWbRn3gzd8zy+IXRH10PXOxFCl6kL4uMBCq0urF9sHVQzg0nT
7xqwhDMYXGIu45wqUMk+s9xoD4lr9NLA1nZQq/Y1ZuP2Uqarrm+lZtKNeO6b
M8TBR4GLGPm6D8NfagE/MR5Oc4PNusMONy9uyVfo3UbdoNspxUcCeY1CKKy0
aLeRNFGcnvsY+irFOAoCyqpMTMOJmnZveCFbC8GmlnyKFFvL17iw3BfvNBgq
Cs/u9l6GTeEd+S61612VFbSWtkV+05zCL1tf/Gfzd7N+MX/iyd0YgCYJrU/J
oQV37aGBpUo3GBHq3uPa0LXGv98Br6AH2UnkI2Qo+qm0zp+FXseebPpDTlPY
rvh/VryWtklyAAA=
<!-- [rfced] Terminology
a) Throughout the text, the following term appears to be used
inconsistently. Please review these occurrences and let us
know if/how they may be made consistent.
URL Pattern vs. URL pattern
b) We note the following forms. Are these terms different or are any
updates needed for consistency (i.e., should any of these forms be
updated as '"Use-As-Dictionary" response header')?
"Use-As-Dictionary" response header (3 instances)
Use-As-Dictionary header (4 instances)
Use-As-Dictionary response (1 instance)
--> -->
<!-- [rfced] FYI - We have added an expansion for the following
abbreviation upon first use per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review each expansion in the document to
ensure correctness.
Cross-Origin Resource Sharing (CORS)
-->
<!-- [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.
-->
</back>
</rfc> </rfc>
 End of changes. 110 change blocks. 
710 lines changed or deleted 526 lines changed or added

This html diff was produced by rfcdiff 1.48.