rfc9842.original   rfc9842.txt 
HTTP P. Meenan, Ed. Internet Engineering Task Force (IETF) P. Meenan, Ed.
Internet-Draft Google LLC Request for Comments: 9842 Google LLC
Intended status: Standards Track Y. Weiss, Ed. Category: Standards Track Y. Weiss, Ed.
Expires: 1 March 2025 Shopify Inc ISSN: 2070-1721 Shopify Inc
28 August 2024 August 2025
Compression Dictionary Transport Compression Dictionary Transport
draft-ietf-httpbis-compression-dictionary-19
Abstract Abstract
This document specifies a mechanism for dictionary-based compression This document specifies a mechanism for dictionary-based compression
in the Hypertext Transfer Protocol (HTTP). By utilizing this in the Hypertext Transfer Protocol (HTTP). By utilizing this
technique, clients and servers can reduce the size of transmitted technique, clients and servers can reduce the size of transmitted
data, leading to improved performance and reduced bandwidth data, leading to improved performance and reduced bandwidth
consumption. This document extends existing HTTP compression methods consumption. This document extends existing HTTP compression methods
and provides guidelines for the delivery and use of compression and provides guidelines for the delivery and use of compression
dictionaries within the HTTP protocol. dictionaries within the HTTP protocol.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-
dictionary/.
Discussion of this document takes place on the HTTP Working Group
mailing list (mailto:ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/. Working Group
information can be found at https://httpwg.org/.
Source for this draft and an issue tracker can be found at
https://github.com/httpwg/http-extensions/labels/compression-
dictionary.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 1 March 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9842.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Use Cases
1.1.1. Version Upgrade . . . . . . . . . . . . . . . . . . . 3 1.1.1. Version Upgrade
1.1.2. Common Content . . . . . . . . . . . . . . . . . . . 4 1.1.2. Common Content
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5 1.2. Notational Conventions
2. Dictionary Negotiation . . . . . . . . . . . . . . . . . . . 6 2. Dictionary Negotiation
2.1. Use-As-Dictionary . . . . . . . . . . . . . . . . . . . . 6 2.1. Use-As-Dictionary
2.1.1. match . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. "match"
2.1.2. match-dest . . . . . . . . . . . . . . . . . . . . . 7 2.1.2. "match-dest"
2.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.3. "id"
2.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.4. "type"
2.1.5. Examples . . . . . . . . . . . . . . . . . . . . . . 8 2.1.5. Examples
2.2. Available-Dictionary . . . . . . . . . . . . . . . . . . 8 2.2. Available-Dictionary
2.2.1. Dictionary freshness requirement . . . . . . . . . . 9 2.2.1. Dictionary Freshness Requirement
2.2.2. Dictionary URL matching . . . . . . . . . . . . . . . 9 2.2.2. Dictionary URL Matching
2.2.3. Multiple matching dictionaries . . . . . . . . . . . 10 2.2.3. Multiple Matching Dictionaries
2.3. Dictionary-ID . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Dictionary-ID
3. The 'compression-dictionary' Link Relation Type . . . . . . . 11 3. The "compression-dictionary" Link Relation Type
4. Dictionary-Compressed Brotli . . . . . . . . . . . . . . . . 11 4. Dictionary-Compressed Brotli
5. Dictionary-Compressed Zstandard . . . . . . . . . . . . . . . 12 5. Dictionary-Compressed Zstandard
6. Negotiating the content encoding . . . . . . . . . . . . . . 13 6. Negotiating the Content Encoding
6.1. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 13 6.1. Accept-Encoding
6.2. Content-Encoding . . . . . . . . . . . . . . . . . . . . 13 6.2. Content-Encoding
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations
7.1. Content Encoding . . . . . . . . . . . . . . . . . . . . 14 7.1. Content Encoding Registration
7.2. Header Field Registration . . . . . . . . . . . . . . . . 14 7.2. Header Field Registration
7.3. Link Relation Registration . . . . . . . . . . . . . . . 15 7.3. Link Relation Registration
8. Compatibility Considerations . . . . . . . . . . . . . . . . 15 8. Compatibility Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations
9.1. Changing content . . . . . . . . . . . . . . . . . . . . 15 9.1. Changing Content
9.2. Reading content . . . . . . . . . . . . . . . . . . . . . 16 9.2. Reading Content
9.3. Security Mitigations . . . . . . . . . . . . . . . . . . 16 9.3. Security Mitigations
9.3.1. Cross-origin protection . . . . . . . . . . . . . . . 16 9.3.1. Cross-Origin Protection
9.3.2. Response readability . . . . . . . . . . . . . . . . 16 9.3.2. Response Readability
9.3.3. Server Responsibility . . . . . . . . . . . . . . . . 17 9.3.3. Server Responsibility
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 10. Privacy Considerations
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses
1. Introduction 1. Introduction
This specification defines a mechanism for using designated [HTTP] This specification defines a mechanism for using designated HTTP
responses as an external dictionary for future HTTP responses for [HTTP] responses as an external dictionary for future HTTP responses
compression schemes that support using external dictionaries (e.g., for compression schemes that support using external dictionaries
Brotli [RFC7932] and Zstandard [RFC8878]). (e.g., Brotli [RFC7932] and Zstandard [RFC8878]).
This document describes the HTTP headers used for negotiating This document describes the HTTP headers used for negotiating
dictionary usage and registers content encoding values for dictionary usage and registers content-encoding values for
compressing with Brotli and Zstandard using a negotiated dictionary. compressing with Brotli and Zstandard using a negotiated dictionary.
The negotiation of dictionary usage leverages HTTP's content The negotiation of dictionary usage leverages HTTP's content
negotiation (see Section 12 of [HTTP]) and is usable with all negotiation (see Section 12 of [HTTP]) and is usable with all
versions of HTTP. versions of HTTP.
1.1. Use Cases 1.1. Use Cases
Any HTTP response can be specified to be used as a compression Any HTTP response can be specified for use as a compression
dictionary for future HTTP requests which provides a lot of dictionary for future HTTP requests, which provides a lot of
flexibility. There are two common use cases that are seen flexibility. Two common use cases that are seen frequently are
frequently: described below.
1.1.1. Version Upgrade 1.1.1. Version Upgrade
Using a previous version of a resource as a dictionary for a newer Using a previous version of a resource as a dictionary for a newer
version enables delivery of a delta-compressed version of the version enables delivery of a delta-compressed version of the
changes, usually resulting in significantly smaller responses than changes, usually resulting in significantly smaller responses than
can be achieved by compression alone. what can be achieved by compression alone.
For example: For example:
Client Server Client Server
| | | |
| GET /app.v1.js | | GET /app.v1.js |
|------------------------------------------------->| |------------------------------------------------->|
| | | |
| 200 OK | | 200 OK |
| Use-As-Dictionary: match="/app*js" | | Use-As-Dictionary: match="/app*js" |
skipping to change at page 4, line 35 skipping to change at line 153
| 200 OK | | 200 OK |
| Content-Encoding: dcb | | Content-Encoding: dcb |
| <delta-compressed app.v2.js resource - 1KB> | | <delta-compressed app.v2.js resource - 1KB> |
|<-------------------------------------------------| |<-------------------------------------------------|
| | | |
Figure 1: Version Upgrade Example Figure 1: Version Upgrade Example
1.1.2. Common Content 1.1.2. Common Content
If several resources share common patterns in their responses then it If several resources share common patterns in their responses, then
can be useful to reference an external dictionary that contains those it can be useful to reference an external dictionary that contains
common patterns, effectively compressing them out of the responses. those common patterns, effectively compressing them out of the
Some examples of this are common template HTML for similar pages responses. Some examples of this are common template HTML for
across a site and common keys and values in API calls. similar pages across a site and common keys and values in API calls.
For example: For example:
Client Server Client Server
| | | |
| GET /index.html | | GET /index.html |
|--------------------------------------------------->| |--------------------------------------------------->|
| | | |
| 200 OK | | 200 OK |
| Link: <.../dict>; rel="compression-dictionary" | | Link: <.../dict>; rel="compression-dictionary" |
skipping to change at page 6, line 14 skipping to change at line 217
This document uses the line folding strategies described in This document uses the line folding strategies described in
[FOLDING]. [FOLDING].
This document also uses terminology from [HTTP] and [HTTP-CACHING]. This document also uses terminology from [HTTP] and [HTTP-CACHING].
2. Dictionary Negotiation 2. Dictionary Negotiation
2.1. Use-As-Dictionary 2.1. Use-As-Dictionary
When responding to a HTTP Request, a server can advertise that the When responding to an HTTP Request, a server can advertise that the
response can be used as a dictionary for future requests for URLs response can be used as a dictionary for future requests for URLs
that match the rules specified in the Use-As-Dictionary response that match the rules specified in the "Use-As-Dictionary" response
header. header.
The Use-As-Dictionary response header is a Structured Field The "Use-As-Dictionary" response header is a Structured Field
[STRUCTURED-FIELDS] Dictionary with values for "match", "match-dest", [STRUCTURED-FIELDS] Dictionary with values for "match", "match-dest",
"id", and "type". "id", and "type".
2.1.1. match 2.1.1. "match"
The "match" value of the Use-As-Dictionary header is a String value The "match" value of the "Use-As-Dictionary" response header is a
that provides the URL Pattern to use for request matching (see String value that provides the URL Pattern to use for request
[URLPATTERN]). matching (see [URLPATTERN]).
The URL Pattern used for matching does not support using regular The URL Pattern used for matching does not support using regular
expressions. expressions.
The following algorithm is used to validate that a given String value The following algorithm is used to validate that a given String value
is a valid URL Pattern that does not use regular expressions and is is a valid URL Pattern that does not use regular expressions and is
for the same Origin (Section 4.3.1 of [HTTP]) as the dictionary. It for the same Origin (Section 4.3.1 of [HTTP]) as the dictionary. It
will return TRUE for a valid match pattern and FALSE for an invalid will return TRUE for a valid match pattern and FALSE for an invalid
pattern that MUST NOT be used: pattern that MUST NOT be used.
1. Let MATCH be the value of "match" for the given dictionary. 1. Let MATCH be the value of "match" for the given dictionary.
2. Let URL be the URL of the dictionary request. 2. Let URL be the URL of the dictionary request.
3. Let PATTERN be a URL pattern created by running the steps to 3. Let PATTERN be a URL pattern created by running the steps to
create a URL pattern by setting input=MATCH, and baseURL=URL (see create a URL pattern by setting input=MATCH and baseURL=URL (see
Part create of [URLPATTERN]). Part create of [URLPATTERN]).
4. If the result of running the "has regexp groups" steps for 4. If the result of running the "has regexp groups" steps for
PATTERN returns TRUE then return FALSE (see Part has regexp PATTERN returns TRUE, then return FALSE (see Part has regexp
groups of [URLPATTERN]). groups of [URLPATTERN]).
5. Return TRUE. 5. Return TRUE.
The "match" value is required and MUST be included in the Use-As- The "match" value is required and MUST be included in the "Use-As-
Dictionary response header for the dictionary to be considered valid. Dictionary" response header for the dictionary to be considered
valid.
Operating at the HTTP-level, the specified match patterns will Operating at the HTTP level, the specified match patterns will
operate on the percent-encoded version of the URL path (see Section 2 operate on the percent-encoded version of the URL path (see Section 2
of [URL]). of [URL]).
For example the URL "http://www.example.com/düsseldorf" would be For example, the URL "http://www.example.com/düsseldorf" would be
encoded as "http://www.example.com/d%C3%BCsseldorf" and a relevant encoded as "http://www.example.com/d%C3%BCsseldorf" and a relevant
match pattern would be: match pattern would be:
Use-As-Dictionary: match="/d%C3%BCsseldorf" Use-As-Dictionary: match="/d%C3%BCsseldorf"
2.1.2. match-dest 2.1.2. "match-dest"
The "match-dest" value of the Use-As-Dictionary header is an Inner The "match-dest" value of the Use-As-Dictionary header is an Inner
List of String values that provides a list of Fetch request List of String values that provides a list of Fetch request
destinations for the dictionary to match (see Part RequestDestination destinations for the dictionary to match (see Part RequestDestination
of [FETCH]). of [FETCH]).
An empty list for "match-dest" MUST match all destinations. An empty list for "match-dest" MUST match all destinations.
For clients that do not support request destinations, the client MUST For clients that do not support request destinations, the client MUST
treat it as an empty list and match all destinations. treat it as an empty list and match all destinations.
The "match-dest" value is optional and defaults to an empty list. The "match-dest" value is optional and defaults to an empty list.
2.1.3. id 2.1.3. "id"
The "id" value of the Use-As-Dictionary header is a String value that The "id" value of the Use-As-Dictionary header is a String value that
specifies a server identifier for the dictionary. If an "id" value specifies a server identifier for the dictionary. If an "id" value
is present and has a string length longer than zero then it MUST be is present and has a string length longer than zero, then it MUST be
sent to the server in a "Dictionary-ID" request header when the sent to the server in a "Dictionary-ID" request header when the
client sends an "Available-Dictionary" request header for the same client sends an "Available-Dictionary" request header for the same
dictionary (see Section 2.2). dictionary (see Section 2.2).
The server identifier MUST be treated as an opaque string by the The server identifier MUST be treated as an opaque string by the
client. client.
The server identifier MUST NOT be relied upon by the server to The server identifier MUST NOT be relied upon by the server to
guarantee the contents of the dictionary. The dictionary hash MUST guarantee the contents of the dictionary. The dictionary hash MUST
be validated before use. be validated before use.
The "id" value string length (after any decoding) supports up to 1024 The "id" value string length (after any decoding) supports up to 1024
characters. characters.
The "id" value is optional and defaults to the empty string. The "id" value is optional and defaults to the empty string.
2.1.4. type 2.1.4. "type"
The "type" value of the Use-As-Dictionary header is a Token value The "type" value of the Use-As-Dictionary header is a Token value
that describes the file format of the supplied dictionary. that describes the file format of the supplied dictionary.
"raw" is defined as a dictionary format which represents an "raw" is defined as a dictionary format that represents an
unformatted blob of bytes suitable for any compression scheme to use. unformatted blob of bytes suitable for any compression scheme to use.
If a client receives a dictionary with a type that it does not If a client receives a dictionary with a type that it does not
understand, it MUST NOT use the dictionary. understand, it MUST NOT use the dictionary.
The "type" value is optional and defaults to "raw". The "type" value is optional and defaults to "raw".
2.1.5. Examples 2.1.5. Examples
2.1.5.1. Path Prefix 2.1.5.1. Path Prefix
skipping to change at page 8, line 44 skipping to change at line 343
A response that contained a response header: A response that contained a response header:
Use-As-Dictionary: match="/app/*/main.js" Use-As-Dictionary: match="/app/*/main.js"
Would match any path that starts with "/app/" and ends with Would match any path that starts with "/app/" and ends with
"/main.js". "/main.js".
2.2. Available-Dictionary 2.2. Available-Dictionary
When a HTTP client makes a request for a resource for which it has an When an HTTP client makes a request for a resource for which it has
appropriate dictionary, it can add a "Available-Dictionary" request an appropriate dictionary, it can add an "Available-Dictionary"
header to the request to indicate to the server that it has a request header to the request to indicate to the server that it has a
dictionary available to use for compression. dictionary available to use for compression.
The "Available-Dictionary" request header is a Structured Field The "Available-Dictionary" request header is a Structured Field
[STRUCTURED-FIELDS] Byte Sequence containing the [SHA-256] hash of [STRUCTURED-FIELDS] Byte Sequence containing the SHA-256 [SHA-256]
the contents of a single available dictionary. hash of the contents of a single available dictionary.
The client MUST only send a single "Available-Dictionary" request The client MUST only send a single "Available-Dictionary" request
header with a single hash value for the best available match that it header with a single hash value for the best available match that it
has available. has available.
For example: For example:
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=: Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
2.2.1. Dictionary freshness requirement 2.2.1. Dictionary Freshness Requirement
To be considered as a match, the dictionary resource MUST be either To be considered as a match, the dictionary resource MUST be either
fresh [HTTP-CACHING] or allowed to be served stale (see eg fresh [HTTP-CACHING] or allowed to be served stale (see [RFC5861]).
[RFC5861]).
2.2.2. Dictionary URL matching 2.2.2. Dictionary URL Matching
When a dictionary is stored as a result of a "Use-As-Dictionary" When a dictionary is stored as a result of a "Use-As-Dictionary"
directive, it includes a "match" string and optional "match-dest" directive, it includes a "match" string and an optional "match-dest"
string that are used to match an outgoing request from a client to string that are used to match an outgoing request from a client to
the available dictionaries. the available dictionaries.
To see if an outbound request matches a given dictionary, the To see if an outbound request matches a given dictionary, the
following algorithm will return TRUE for a successful match and FALSE following algorithm will return TRUE for a successful match and FALSE
for no-match: for no-match:
1. If the current client supports request destinations and a "match- 1. If the current client supports request destinations and a "match-
dest" string was provided with the dictionary: dest" string was provided with the dictionary:
* Let DEST be the value of "match-dest" for the given * Let DEST be the value of "match-dest" for the given
dictionary. dictionary.
* Let REQUEST_DEST be the value of the destination for the * Let REQUEST_DEST be the value of the destination for the
current request. current request.
* If DEST is not an empty list and if REQUEST_DEST is not in the * If DEST is not an empty list and if REQUEST_DEST is not in the
DEST list of destinations, return FALSE DEST list of destinations, return FALSE.
2. Let BASEURL be the URL of the dictionary request. 2. Let BASEURL be the URL of the dictionary request.
3. Let URL represent the URL of the outbound request being checked. 3. Let URL represent the URL of the outbound request being checked.
4. If the Origin of BASEURL and the Origin of URL are not the same, 4. If the Origin of BASEURL and the Origin of URL are not the same,
return FALSE (see Section 4.3.1 of [HTTP]). return FALSE (see Section 4.3.1 of [HTTP]).
5. Let MATCH be the value of "match" for the given dictionary. 5. Let MATCH be the value of "match" for the given dictionary.
6. Let PATTERN be a URL pattern created by running the steps to 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 create a URL pattern by setting input=MATCH and baseURL=URL (see
Part create of [URLPATTERN]). Part create of [URLPATTERN]).
7. Return the result of running the "match" steps on PATTERN with 7. Return the result of running the "match" steps on PATTERN with
input=URL which will check for a match between the request URL input=URL, which will check for a match between the request URL
and the supplied "match" string (see Part match of [URLPATTERN]). and the supplied "match" string (see Part match of [URLPATTERN]).
2.2.3. Multiple matching dictionaries 2.2.3. Multiple Matching Dictionaries
When there are multiple dictionaries that match a given request URL, When there are multiple dictionaries that match a given request URL,
the client MUST pick a single dictionary using the following rules: the client MUST pick a single dictionary using the following rules:
1. For clients that support request destinations, a dictionary that 1. For clients that support request destinations, a dictionary that
specifies and matches a "match-dest" takes precedence over a specifies and matches a "match-dest" takes precedence over a
match that does not use a destination. match that does not use a destination.
2. Given equivalent destination precedence, the dictionary with the 2. Given equivalent destination precedence, the dictionary with the
longest "match" takes precedence. longest "match" takes precedence.
3. Given equivalent destination and match length precedence, the 3. Given equivalent destination and match length precedence, the
most recently fetched dictionary takes precedence. most recently fetched dictionary takes precedence.
2.3. Dictionary-ID 2.3. Dictionary-ID
When a HTTP client makes a request for a resource for which it has an When an HTTP client makes a request for a resource for which it has
appropriate dictionary and the dictionary was stored with a server- an appropriate dictionary and the dictionary was stored with a
provided "id" in the Use-As-Dictionary response then the client MUST server-provided "id" in the Use-As-Dictionary response, the client
echo the stored "id" in a "Dictionary-ID" request header. MUST echo the stored "id" in a "Dictionary-ID" request header.
The "Dictionary-ID" request header is a Structured Field The "Dictionary-ID" request header is a Structured Field
[STRUCTURED-FIELDS] String of up to 1024 characters (after any [STRUCTURED-FIELDS] String of up to 1024 characters (after any
decoding) and MUST be identical to the server-provided "id". decoding) and MUST be identical to the server-provided "id".
For example, given a HTTP response that set a dictionary ID: For example, given an HTTP response that set a dictionary ID:
Use-As-Dictionary: match="/app/*/main.js", id="dictionary-12345" Use-As-Dictionary: match="/app/*/main.js", id="dictionary-12345"
A future request that matches the given dictionary will include both A future request that matches the given dictionary will include both
the hash and the ID: the hash and the ID:
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=: Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Dictionary-ID: "dictionary-12345" Dictionary-ID: "dictionary-12345"
3. The 'compression-dictionary' Link Relation Type 3. The "compression-dictionary" Link Relation Type
This specification defines the 'compression-dictionary' link relation This specification defines the "compression-dictionary" link relation
type [WEB-LINKING] that provides a mechanism for a HTTP response to type [WEB-LINKING] that provides a mechanism for an HTTP response to
provide a URL for a compression dictionary that is related to, but provide a URL for a compression dictionary that is related to but not
not directly used by the current HTTP response. directly used by the current HTTP response.
The 'compression-dictionary' link relation type indicates that The "compression-dictionary" link relation type indicates that
fetching and caching the specified resource is likely to be fetching and caching the specified resource is likely to be
beneficial for future requests. The response to some of those future beneficial for future requests. The response to some of those future
requests are likely to be able to use the indicated resource as a requests likely have the ability to use the indicated resource as a
compression dictionary. compression dictionary.
Clients can fetch the provided resource at a time that they determine Clients can fetch the provided resource at a time that they determine
would be appropriate. would be appropriate.
The response to the fetch for the compression dictionary needs to The response to the fetch for the compression dictionary needs to
include a "Use-As-Dictionary" and caching response headers for it to include a "Use-As-Dictionary" and caching response headers for it to
be usable as a compression dictionary. The link relation only be usable as a compression dictionary. The link relation only
provides the mechanism for triggering the fetch of the dictionary. provides the mechanism for triggering the fetch of the dictionary.
skipping to change at page 11, line 46 skipping to change at line 482
A "Dictionary-Compressed Brotli" stream has a fixed header that is A "Dictionary-Compressed Brotli" stream has a fixed header that is
followed by a Shared Brotli [SHARED-BROTLI] stream. The header followed by a Shared Brotli [SHARED-BROTLI] stream. The header
consists of a fixed 4-byte sequence and a 32-byte hash of the consists of a fixed 4-byte sequence and a 32-byte hash of the
external dictionary that was used. The Shared Brotli stream is external dictionary that was used. The Shared Brotli stream is
created using the referenced external dictionary and a compression created using the referenced external dictionary and a compression
window that is at most 16 MB in size. window that is at most 16 MB in size.
The dictionary used for the "dcb" content encoding is a "raw" 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 dictionary type as defined in Section 2.1.4 and is treated as a
prefix dictionary as defined in section 9.2 of the Shared Brotli prefix dictionary as defined in Section 9.2 of [SHARED-BROTLI].
Compressed Data Format draft. [SHARED-BROTLI]
The 36-byte fixed header is as follows: The 36-byte fixed header is as follows:
Magic_Number: 4 fixed bytes: 0xff, 0x44, 0x43, 0x42. Magic_Number: 4 fixed bytes -- 0xff, 0x44, 0x43, 0x42.
SHA_256_Hash: 32 bytes. SHA-256 hash digest of the dictionary SHA_256_Hash: 32 bytes. SHA-256 hash digest of the dictionary
[SHA-256]. [SHA-256].
Clients that announce support for dcb content encoding MUST be able Clients that announce support for dcb content encoding MUST be able
to decompress resources that were compressed with a window size of up to decompress resources that were compressed with a window size of up
to 16 MB. to 16 MB.
With Brotli compression, the full dictionary is available during With Brotli compression, the full dictionary is available during
compression and decompression independent of the compression window, compression and decompression independent of the compression window,
skipping to change at page 12, line 29 skipping to change at line 512
The "dcz" content encoding identifies a resource that is a The "dcz" content encoding identifies a resource that is a
"Dictionary-Compressed Zstandard" stream. "Dictionary-Compressed Zstandard" stream.
A "Dictionary-Compressed Zstandard" stream is a binary stream that A "Dictionary-Compressed Zstandard" stream is a binary stream that
starts with a 40-byte fixed header and is followed by a Zstandard starts with a 40-byte fixed header and is followed by a Zstandard
[RFC8878] stream of the response that has been compressed with an [RFC8878] stream of the response that has been compressed with an
external dictionary. external dictionary.
The dictionary used for the "dcz" content encoding is a "raw" The dictionary used for the "dcz" content encoding is a "raw"
dictionary type as defined in Section 2.1.4 and is treated as a raw dictionary type as defined in Section 2.1.4 and is treated as a raw
dictionary as per section 5 of RFC 8878. dictionary as per Section 5 of [RFC8878].
The 40-byte header consists of a fixed 8-byte sequence followed by 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 the 32-byte SHA-256 hash of the external dictionary that was used to
compress the resource: compress the resource:
Magic_Number: 8 fixed bytes: 0x5e, 0x2a, 0x4d, 0x18, 0x20, 0x00, Magic_Number: 8 fixed bytes -- 0x5e, 0x2a, 0x4d, 0x18, 0x20, 0x00,
0x00, 0x00. 0x00, 0x00.
SHA_256_Hash: 32 bytes. SHA-256 hash digest of the dictionary SHA_256_Hash: 32 bytes. SHA-256 hash digest of the dictionary
[SHA-256]. [SHA-256].
The 40-byte header is a Zstandard skippable frame (little-endian The 40-byte header is a Zstandard skippable frame (little-endian
0x184D2A5E) with a 32-byte length (little-endian 0x00000020) that is 0x184D2A5E) with a 32-byte length (little-endian 0x00000020) that is
compatible with existing Zstandard decoders. compatible with existing Zstandard decoders.
Clients that announce support for dcz content encoding MUST be able Clients that announce support for dcz content encoding MUST be able
to decompress resources that were compressed with a window size of at to 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 least 8 MB or 1.25 times the size of the dictionary, whichever is
greater, up to a maximum of 128 MB. greater, up to a maximum of 128 MB.
The window size used will be encoded in the content (currently, this The window size used will be encoded in the content (currently, this
can be expressed in powers of two only) and it MUST be lower than can be expressed in powers of two only) and it MUST be lower than
this limit. An implementation MAY treat a window size that exceeds this limit. An implementation MAY treat a window size that exceeds
the limit as a decoding error. the limit as a decoding error.
With Zstandard compression, the full dictionary is available during With Zstandard compression, the full dictionary is available during
compression and decompression until the size of the input exceeds the compression and decompression until the size of the input exceeds the
compression window. Beyond that point the dictionary becomes compression window. Beyond that point, the dictionary becomes
unavailable. Using a compression window that is 1.25 times the size unavailable. Using a compression window that is 1.25 times the size
of the dictionary allows for full delta compression of resources that of the dictionary allows for full delta compression of resources that
have grown by 25% between releases while still giving the client have grown by 25% between releases while still giving the client
control over the memory it will need to allocate for a given control over the memory it will need to allocate for a given
response. response.
6. Negotiating the content encoding 6. Negotiating the Content Encoding
When a compression dictionary is available for use compressing the When a compression dictionary is available for use compressing the
response to a given request, the encoding to be used is negotiated response to a given request, the encoding to be used is negotiated
through the regular mechanism for negotiating content encoding in through the regular mechanism for negotiating content encoding in
HTTP through the "Accept-Encoding" request header and "Content- HTTP through the "Accept-Encoding" request header and "Content-
Encoding" response header. Encoding" response header.
The dictionary to use is negotiated separately and advertised in the The dictionary to use is negotiated separately and advertised in the
"Available-Dictionary" request header. "Available-Dictionary" request header.
6.1. Accept-Encoding 6.1. Accept-Encoding
When a dictionary is available for use on a given request, and the When a dictionary is available for use on a given request and the
client chooses to make dictionary-based content-encoding available, client chooses to make dictionary-based content encoding available,
the client adds the dictionary-aware content encodings that it the client adds the dictionary-aware content encodings that it
supports to the "Accept-Encoding" request header. e.g.: supports to the "Accept-Encoding" request header. For example:
Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz
When a client does not have a stored dictionary that matches the When a client does not have a stored dictionary that matches the
request, or chooses not to use one for the request, the client MUST request or chooses not to use one for the request, the client MUST
NOT send its dictionary-aware content-encodings in the "Accept- NOT send its dictionary-aware content encodings in the "Accept-
Encoding" request header. Encoding" request header.
6.2. Content-Encoding 6.2. Content-Encoding
If a server supports one of the dictionary encodings advertised by If a server supports one of the dictionary encodings advertised by
the client and chooses to compress the content of the response using the client and chooses to compress the content of the response using
the dictionary that the client has advertised then it sets the the dictionary that the client has advertised, then it sets the
"Content-Encoding" response header to the appropriate value for the "Content-Encoding" response header to the appropriate value for the
algorithm selected. e.g.: algorithm selected. For example:
Content-Encoding: dcb Content-Encoding: dcb
If the response is cacheable, it MUST include a "Vary" header to If the response is cacheable, it MUST include a "Vary" header to
prevent caches serving dictionary-compressed resources to clients prevent caches from serving dictionary-compressed resources to
that don't support them or serving the response compressed with the clients that don't support them or serving the response compressed
wrong dictionary: with the wrong dictionary. For example:
Vary: accept-encoding, available-dictionary Vary: accept-encoding, available-dictionary
7. IANA Considerations 7. IANA Considerations
7.1. Content Encoding 7.1. Content Encoding Registration
IANA is asked to enter the following into the "HTTP Content Coding
Registry" registry maintained at <https://www.iana.org/assignments/
http-parameters/http-parameters.xhtml>:
* Name: dcb
* Description: "Dictionary-Compressed Brotli" data format.
* Reference: This document
* Notes: Section 4
IANA is asked to enter the following into the "HTTP Content Coding
Registry" registry maintained at <https://www.iana.org/assignments/
http-parameters/http-parameters.xhtml>:
* Name: dcz
* Description: "Dictionary-Compressed Zstandard" data format. IANA has added the following entries to the "HTTP Content Coding
Registry" maintained at <https://www.iana.org/assignments/http-
parameters/>:
* Reference: This document Name: dcb
Description: "Dictionary-Compressed Brotli" data format.
Reference: RFC 9842, Section 4
* Notes: Section 5 Name: dcz
Description: "Dictionary-Compressed Zstandard" data format.
Reference: RFC 9842, Section 5
7.2. Header Field Registration 7.2. Header Field Registration
IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field IANA has added the following entries to the "Hypertext Transfer
Name Registry" registry maintained at Protocol (HTTP) Field Name Registry" maintained at
<https://www.iana.org/assignments/http-fields/http-fields.xhtml> <https://www.iana.org/assignments/http-fields/>:
according to the table below:
+======================+===========+==============================+ +======================+===========+=======================+
| Field Name | Status | Reference | | Field Name | Status | Reference |
+======================+===========+==============================+ +======================+===========+=======================+
| Use-As-Dictionary | permanent | Section 2.1 of this document | | Use-As-Dictionary | permanent | RFC 9842, Section 2.1 |
+----------------------+-----------+------------------------------+ +----------------------+-----------+-----------------------+
| Available-Dictionary | permanent | Section 2.2 of this document | | Available-Dictionary | permanent | RFC 9842, Section 2.2 |
+----------------------+-----------+------------------------------+ +----------------------+-----------+-----------------------+
| Dictionary-ID | permanent | Section 2.3 of this document | | Dictionary-ID | permanent | RFC 9842, Section 2.3 |
+----------------------+-----------+------------------------------+ +----------------------+-----------+-----------------------+
Table 1 Table 1
7.3. Link Relation Registration 7.3. Link Relation Registration
IANA is asked to update the "Link Relation Types" registry maintained IANA has added the following entry to the "Link Relation Types"
at <https://www.iana.org/assignments/link-relations/link- registry maintained at <https://www.iana.org/assignments/link-
relations.xhtml>: relations/>:
* Relation Name: compression-dictionary
* Description: Refers to a compression dictionary used for content Relation Name: compression-dictionary
Description: Refers to a compression dictionary used for content
encoding. encoding.
Reference: RFC 9842, Section 3
* Reference: This document, Section 3
8. Compatibility Considerations 8. Compatibility Considerations
It is not unusual for there to be devices on the network path that It is not unusual for devices to be on the network path that
intercept, inspect and process HTTP requests (web proxies, firewalls, intercept, inspect, and process HTTP requests (web proxies,
intrusion detection systems, etc). To minimize the risk of these firewalls, intrusion detection systems, etc.). To minimize the risk
devices incorrectly processing dictionary-compressed responses, of these devices incorrectly processing dictionary-compressed
compression dictionary transport MUST only be used in secure contexts responses, compression dictionary transport MUST only be used in
(HTTPS). secure contexts (HTTPS).
9. Security Considerations 9. Security Considerations
The security considerations for Brotli [RFC7932], Shared Brotli The security considerations for Brotli [RFC7932], Shared Brotli
[SHARED-BROTLI] and Zstandard [RFC8878] apply to the dictionary-based [SHARED-BROTLI], and Zstandard [RFC8878] apply to the dictionary-
versions of the respective algorithms. based versions of the respective algorithms.
9.1. Changing content 9.1. Changing Content
The dictionary must be treated with the same security precautions as 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
change to the decompressed content. to the decompressed content.
The dictionary is validated using a SHA-256 hash of the content to The dictionary is validated using an SHA-256 hash of the content to
make sure that the client and server are both using the same make sure that the client and server are both using the same
dictionary. The strength of the SHA-256 hash algorithm isn't dictionary. The strength of the SHA-256 hash algorithm isn't
explicitly needed to counter attacks since the dictionary is being explicitly needed to counter attacks since the dictionary is being
served from the same origin as the content. That said, if a weakness served from the same origin as the content. That said, if a weakness
is discovered in SHA-256 and it is determined that the dictionary is discovered in SHA-256 and it is determined that the dictionary
negotiation should use a different hash algorithm, the "Use-As- negotiation should use a different hash algorithm, the "Use-As-
Dictionary" response header can be extended to specify a different Dictionary" response header can be extended to specify a different
algorithm and the server would just ignore any "Available-Dictionary" algorithm and the server would just ignore any "Available-Dictionary"
requests that do not use the updated hash. requests that do not use the updated hash.
9.2. Reading content 9.2. Reading Content
The compression attacks in Section 2.6 of [RFC7457] show that it's a The compression attacks in Section 2.6 of [RFC7457] show that it's a
bad idea to compress data from mixed (e.g. public and private) bad idea to compress data from mixed (e.g., public and private)
sources -- the data sources include not only the compressed data but sources. The data sources include not only the compressed data but
also the dictionaries. For example, if you compress secret cookies also the dictionaries. For example, if secret cookies are compressed
using a public-data-only dictionary, you still leak information about using a public-data-only dictionary, information about the cookies is
the cookies. still leaked.
Not only can the dictionary reveal information about the compressed The dictionary can reveal information about the compressed data and
data, but vice versa, data compressed with the dictionary can reveal vice versa. That is, data compressed with the dictionary can reveal
the contents of the dictionary when an adversary can control parts of 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 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. information about the compressed data.
9.3. Security Mitigations 9.3. Security Mitigations
If any of the mitigations do not pass, the client MUST drop the If any of the mitigations do not pass, the client MUST drop the
response and return an error. response and return an error.
9.3.1. Cross-origin protection 9.3.1. Cross-Origin Protection
To make sure that a dictionary can only impact content from the same To make sure that a dictionary can only impact content from the same
origin where the dictionary was served, the URL Pattern used for origin where the dictionary was served, the URL Pattern used for
matching a dictionary to requests (Section 2.1.1) is guaranteed to be matching a dictionary to requests (Section 2.1.1) is guaranteed to be
for the same origin that the dictionary is served from. for the same origin that the dictionary is served from.
9.3.2. Response readability 9.3.2. Response Readability
For clients, like web browsers, that provide additional protection For clients, like web browsers, that provide additional protection
against the readability of the payload of a response and against user against the readability of the payload of a response and against user
tracking, additional protections MUST be taken to make sure that the tracking, additional protections MUST be taken to make sure that the
use of dictionary-based compression does not reveal information that use of dictionary-based compression does not reveal information that
would not otherwise be available. would not otherwise be available.
In these cases, dictionary compression MUST only be used when both In these cases, dictionary compression MUST only be used when both
the dictionary and the compressed response are fully readable by the the dictionary and the compressed response are fully readable by the
client. client.
In browser terms, that means that both are either same-origin to the 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- context they are being fetched from or that the response is cross-
origin and passes the CORS check (see Part CORS check of [FETCH]). origin and passes the Cross-Origin Resource Sharing (CORS) check (see
Part CORS check of [FETCH]).
9.3.3. Server Responsibility 9.3.3. Server Responsibility
As with any usage of compressed content in a secure context, a As with any usage of compressed content in a secure context, a
potential timing attack exists if the attacker can control any part potential timing attack exists if the attacker can control any part
of the dictionary, or if it can read the dictionary and control any of the dictionary or if it can read the dictionary and control any
part of the content being compressed, while performing multiple part of the content being compressed while performing multiple
requests that vary the dictionary or injected content. Under such an requests that vary the dictionary or injected content. Under such an
attack, the changing size or processing time of the response reveals attack, the changing size or processing time of the response reveals
information about the content, which might be sufficient to read the information about the content, which might be sufficient to read the
supposedly secure response. supposedly secure response.
In general, a server can mitigate such attacks by preventing In general, a server can mitigate such attacks by preventing
variations per request, as in preventing active use of multiple variations per request, as in preventing active use of multiple
dictionaries for the same content, disabling compression when any dictionaries for the same content, disabling compression when any
portion of the content comes from uncontrolled sources, and securing portion of the content comes from uncontrolled sources, and securing
access and control over the dictionary content in the same way as the access and control over the dictionary content in the same way as the
response content. In addition, the following requirements on a response content. In addition, the following requirements on a
server are intended to disable dictionary-aware compression when the server are intended to disable dictionary-aware compression when the
client provides CORS request header fields that indicate a cross- client provides CORS request header fields that indicate a cross-
origin request context. origin request context.
The following algorithm will return FALSE for cross-origin requests The following algorithm will return FALSE for cross-origin requests
where precautions such as not using dictionary-based compression where precautions such as not using dictionary-based compression
should be considered: should be considered:
1. If there is no "Sec-Fetch-Site" request header then return TRUE. 1. If there is no "Sec-Fetch-Site" request header, return TRUE.
2. if the value of the "Sec-Fetch-Site" request header is "same- 2. If the value of the "Sec-Fetch-Site" request header is "same-
origin" then return TRUE. origin", return TRUE.
3. If there is no "Sec-Fetch-Mode" request header then return TRUE. 3. If there is no "Sec-Fetch-Mode" request header, return TRUE.
4. If the value of the "Sec-Fetch-Mode" request header is "navigate" 4. If the value of the "Sec-Fetch-Mode" request header is "navigate"
or "same-origin" then return TRUE. or "same-origin", return TRUE.
5. If the value of the "Sec-Fetch-Mode" request header is "cors": 5. If the value of the "Sec-Fetch-Mode" request header is "cors":
* If the response does not include an "Access-Control-Allow- * If the response does not include an "Access-Control-Allow-
Origin" response header then return FALSE. Origin" response header, return FALSE.
* If the request does not include an "Origin" request header * If the request does not include an "Origin" request header,
then return FALSE. return FALSE.
* If the value of the "Access-Control-Allow-Origin" response * If the value of the "Access-Control-Allow-Origin" response
header is "*" then return TRUE. header is "*", return TRUE.
* If the value of the "Access-Control-Allow-Origin" response * If the value of the "Access-Control-Allow-Origin" response
header matches the value of the "Origin" request header then header matches the value of the "Origin" request header,
return TRUE. return TRUE.
6. return FALSE. 6. Return FALSE.
10. Privacy Considerations 10. Privacy Considerations
Since dictionaries are advertised in future requests using the hash Since dictionaries are advertised in future requests using the hash
of the content of the dictionary, it is possible to abuse the of the content of the dictionary, it is possible to abuse the
dictionary to turn it into a tracking cookie. dictionary to turn it into a tracking cookie.
To mitigate any additional tracking concerns, clients MUST treat To mitigate any additional tracking concerns, clients MUST treat
dictionaries in the same way that they treat cookies [RFC6265]. This dictionaries in the same way that they treat cookies [RFC6265]. This
includes partitioning the storage as cookies are partitioned as well includes partitioning the storage as cookies are partitioned as well
as clearing the dictionaries whenever cookies are cleared. as clearing the dictionaries whenever cookies are cleared.
11. References 11. References
11.1. Normative References 11.1. Normative References
[FETCH] WHATWG, "Fetch - Living Standard", [FETCH] WHATWG, "Fetch Standard", WHATWG Living Standard,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>. Commit snapshot:
<https://fetch.spec.whatwg.org/commit-
snapshots/5a9680638ebfc2b3b7f4efb2bef0b579a2663951/>
[FOLDING] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, [FOLDING] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and "Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/rfc/rfc8792>. <https://www.rfc-editor.org/info/rfc8792>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[HTTP-CACHING] [HTTP-CACHING]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111, Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022, DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>. <https://www.rfc-editor.org/info/rfc9111>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression [RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
and the 'application/zstd' Media Type", RFC 8878, and the 'application/zstd' Media Type", RFC 8878,
DOI 10.17487/RFC8878, February 2021, DOI 10.17487/RFC8878, February 2021,
<https://www.rfc-editor.org/rfc/rfc8878>. <https://www.rfc-editor.org/info/rfc8878>.
[SHA-256] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [SHA-256] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/rfc/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[SHARED-BROTLI] [SHARED-BROTLI]
"Shared Brotli Compressed Data Format", September 2022, Alakuijala, J., Duong, T., Kliuchnikov, E., Szabadka, Z.,
<https://datatracker.ietf.org/doc/draft-vandevenne-shared- and L. Vandevenne, "Shared Brotli Compressed Data Format",
brotli-format/>. RFC 9841, DOI 10.17487/RFC9841, August 2025,
<https://www.rfc-editor.org/info/rfc9841>.
[STRUCTURED-FIELDS] [STRUCTURED-FIELDS]
"Structured Field Values for HTTP", May 2024, Nottingham, M. and P. Kamp, "Structured Field Values for
<https://datatracker.ietf.org/doc/draft-ietf-httpbis- HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
sfbis/>. <https://www.rfc-editor.org/info/rfc9651>.
[URL] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URL] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[URLPATTERN] [URLPATTERN]
WHATWG, "URL Pattern - Living Standard", WHATWG, "URL Pattern Standard", WHATWG Living Standard,
<https://urlpattern.spec.whatwg.org/>. <https://urlpattern.spec.whatwg.org/>. Commit snapshot:
<https://urlpattern.spec.whatwg.org/commit-
snapshots/696b4029d52e5854044bac6b72cdb198cb962ed0/>
[WEB-LINKING] [WEB-LINKING]
Nottingham, M., "Web Linking", RFC 8288, Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/rfc/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
11.2. Informative References 11.2. Informative References
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
<https://www.rfc-editor.org/rfc/rfc5861>. <https://www.rfc-editor.org/info/rfc5861>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/rfc/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data [RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data
Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, Format", RFC 7932, DOI 10.17487/RFC7932, July 2016,
<https://www.rfc-editor.org/rfc/rfc7932>. <https://www.rfc-editor.org/info/rfc7932>.
Authors' Addresses Authors' Addresses
Patrick Meenan (editor) Patrick Meenan (editor)
Google LLC Google LLC
Email: pmeenan@google.com Email: pmeenan@google.com
Yoav Weiss (editor) Yoav Weiss (editor)
Shopify Inc Shopify Inc
Email: yoav.weiss@shopify.com Email: yoav.weiss@shopify.com
 End of changes. 108 change blocks. 
265 lines changed or deleted 236 lines changed or added

This html diff was produced by rfcdiff 1.48.