draft-ietf-httpbis-compression-dictionary-00.txt   draft-ietf-httpbis-compression-dictionary-latest.txt 
HTTP Working Group P. Meenan, Ed. HTTP Working Group P. Meenan, Ed.
Internet-Draft Y. Weiss, Ed. Internet-Draft Y. Weiss, Ed.
Intended status: Standards Track Google LLC Intended status: Standards Track Google LLC
Expires: March 14, 2024 September 11, 2023 Expires: May 26, 2024 November 23, 2023
Compression Dictionary Transport Compression Dictionary Transport
draft-ietf-httpbis-compression-dictionary-00 draft-ietf-httpbis-compression-dictionary-latest
Abstract Abstract
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 responses as an external dictionary for future HTTP responses for
compression schemes that support using external dictionaries (e.g., compression schemes that support using external dictionaries (e.g.,
Brotli [RFC7932] and Zstandard [RFC8878]). Brotli [RFC7932] and Zstandard [RFC8878]).
About This Document About This Document
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2024. This Internet-Draft will expire on May 26, 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Dictionary Negotiation . . . . . . . . . . . . . . . . . . . 3 2. Dictionary Negotiation . . . . . . . . . . . . . . . . . . . 3
2.1. Use-As-Dictionary . . . . . . . . . . . . . . . . . . . . 3 2.1. Use-As-Dictionary . . . . . . . . . . . . . . . . . . . . 3
2.1.1. match . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. match . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. ttl . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. match-search . . . . . . . . . . . . . . . . . . . . 4
2.1.3. type . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.3. match-dest . . . . . . . . . . . . . . . . . . . . . 4
2.1.4. hashes . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.4. ttl . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.5. Examples . . . . . . . . . . . . . . . . . . . . . . 5 2.1.5. type . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.6. Examples . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Available-Dictionary . . . . . . . . . . . . . . . . . . 5 2.2. Available-Dictionary . . . . . . . . . . . . . . . . . . 5
2.2.1. Dictionary freshness requirement . . . . . . . . . . 6 2.2.1. Dictionary freshness requirement . . . . . . . . . . 6
2.2.2. Dictionary URL matching . . . . . . . . . . . . . . . 6 2.2.2. Dictionary URL matching . . . . . . . . . . . . . . . 6
2.2.3. Multiple matching dictionaries . . . . . . . . . . . 7 2.2.3. Multiple matching dictionaries . . . . . . . . . . . 7
2.3. Content-Dictionary . . . . . . . . . . . . . . . . . . . 7
3. Negotiating the compression algorithm . . . . . . . . . . . . 7 3. Negotiating the compression algorithm . . . . . . . . . . . . 7
3.1. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 8 3.1. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 8
3.2. Content-Encoding . . . . . . . . . . . . . . . . . . . . 8 3.2. Content-Encoding . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. Content Encoding . . . . . . . . . . . . . . . . . . . . 8 4.1. Content Encoding . . . . . . . . . . . . . . . . . . . . 8
4.2. Header Field Registration . . . . . . . . . . . . . . . . 9 4.2. Header Field Registration . . . . . . . . . . . . . . . . 9
5. Compatibility Considerations . . . . . . . . . . . . . . . . 9 5. Compatibility Considerations . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Changing content . . . . . . . . . . . . . . . . . . . . 9 6.1. Changing content . . . . . . . . . . . . . . . . . . . . 9
6.2. Reading content . . . . . . . . . . . . . . . . . . . . . 9 6.2. Reading content . . . . . . . . . . . . . . . . . . . . . 10
6.3. Security Mitigations . . . . . . . . . . . . . . . . . . 10 6.3. Security Mitigations . . . . . . . . . . . . . . . . . . 10
6.3.1. Cross-origin protection . . . . . . . . . . . . . . . 10 6.3.1. Cross-origin protection . . . . . . . . . . . . . . . 10
6.3.2. Response readability . . . . . . . . . . . . . . . . 10 6.3.2. Response readability . . . . . . . . . . . . . . . . 10
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 responses as an external dictionary for future HTTP responses for
compression schemes that support using external dictionaries (e.g., compression schemes that support using external dictionaries (e.g.,
Brotli [RFC7932] and Zstandard [RFC8878]). Brotli [RFC7932] and Zstandard [RFC8878]).
This document describes the HTTP headers used for negotiating This document describes the HTTP headers used for negotiating
skipping to change at page 3, line 27 skipping to change at page 3, line 28
This document uses the line folding strategies described in This document uses the line folding strategies described in
[FOLDING]. [FOLDING].
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 a 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 pattern 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] sf-dictionary with values for "match", "ttl", [STRUCTURED-FIELDS] sf-dictionary with values for "match", "match-
"type" and "hashes". search", "match-dest", "ttl", and "type".
2.1.1. match 2.1.1. match
The "match" value of the Use-As-Dictionary header is a sf-string The "match" value of the Use-As-Dictionary header is a sf-string
value that provides an URL-matching pattern for requests where the value that provides the "pathname" of a URLPattern
dictionary can be used. (https://urlpattern.spec.whatwg.org/#dom-urlpatterninit-pathname).
The sf-string is parsed as a URL [URL], and supports absolute URLs as
well as relative URLs. When stored, any relative URLs MUST be
expanded so that only absolute URL patterns are used for matching
against requests.
The match URL supports using * as a wildcard within the match string The "match" is a [URL] path relative to the full request URL of the
for pattern-matching multiple URLs. URLs with a natural * in them dictionary. The request URL for the dictionary itself is used as the
are not directly supported unless they can rely on the behavior of * "baseURL" for constructing the URLPattern
matching an arbitrary string. (https://urlpattern.spec.whatwg.org/) that is used for matching the
dictionary to relevant requests when running Section 2.2.2.
The [Origin] of the URL in the "match" pattern MUST be the same as The URLPattern used for request matching does not support regular
the origin of the request that specifies the "Use-As-Dictionary" expressions (https://urlpattern.spec.whatwg.org/#token-type-regexp)
response and MUST not include a * wildcard. in the "match".
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 sf-dictionary for the dictionary to be considered valid. Dictionary sf-dictionary for the dictionary to be considered valid.
2.1.2. ttl 2.1.2. match-search
The "match-search" value of the Use-As-Dictionary header is a sf-
string value that provides the "search" of a URLPattern
(https://urlpattern.spec.whatwg.org/#dom-urlpatterninit-search).
The "match-search" is the match pattern for the searchpart of the
request [URL] and does not support regular expressions.
The "match-search" value is optional and defaults to the asterisk
wildcard token "*".
2.1.3. match-dest
The "match-dest" value of the Use-As-Dictionary header is a sf-string
value that provides a request destination
(https://fetch.spec.whatwg.org/#concept-request-destination).
An empty string for "match-dest" MUST match all destinations.
For clients that do not support request destinations or if the value
of "match-dest" is a value that is not supported by the client then
the client MUST treat it as an empty string and match all
destinations.
The "match-dest" value is optional and defaults to the empty string.
2.1.4. ttl
The "ttl" value of the Use-As-Dictionary header is a sf-integer value The "ttl" value of the Use-As-Dictionary header is a sf-integer value
that provides the time in seconds that the dictionary is valid for that provides the time in seconds that the dictionary is valid for
(time to live). (time to live).
The "ttl" is independent of the cache lifetime of the resource being The "ttl" is independent of the cache lifetime of the resource being
used for the dictionary. If the underlying resource is evicted from used for the dictionary. If the underlying resource is evicted from
cache then it is also removed but this allows for setting an explicit cache then it is also removed but this allows for setting an explicit
time to live for use as a dictionary independent of the underlying time to live for use as a dictionary independent of the underlying
resource in cache. Expired resources can still be useful as resource in cache. Expired resources can still be useful as
dictionaries while they are in cache and can be used for fetching dictionaries while they are in cache and can be used for fetching
updates of the expired resource. It can also be useful to updates of the expired resource. It can also be useful to
artificially limit the life of a dictionary in cases where the artificially limit the life of a dictionary in cases where the
dictionary is updated frequently which can help limit the number of dictionary is updated frequently which can help limit the number of
possible incoming dictionary variations. possible incoming dictionary variations.
The "ttl" value is optional and defaults to 31536000 (1 year). The "ttl" value is optional and defaults to 1209600 (14 days).
2.1.3. type 2.1.5. type
The "type" value of the Use-As-Dictionary header is a sf-string value The "type" value of the Use-As-Dictionary header is a sf-string value
that describes the file format of the supplied dictionary. that describes the file format of the supplied dictionary.
"raw" is the only defined dictionary format which represents an "raw" is the only defined dictionary format which 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.4. hashes 2.1.6. Examples
The "hashes" value of the Use-As-Dictionary header is a inner-list
value that provides a list of supported hash algorithms in order of
server preference.
The dictionaries are identified by the hash of their contents and
this value allows for negotiation of the algorithm to use.
The "hashes" value is optional and defaults to (sha-256).
2.1.5. Examples
2.1.5.1. Path Prefix 2.1.6.1. Path Prefix
A response that contained a response header: A response that contained a response header:
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
Use-As-Dictionary: \ Use-As-Dictionary: \
match="/product/*", ttl=604800, hashes=(sha-256 sha-512) match="/product/*", match-dest="document", ttl=604800
Would specify matching any URL with a path prefix of /product/ on the Would specify matching any document request for a URL with a path
same [Origin] as the original request, expiring as a dictionary in 7 prefix of /product/ on the same [Origin] as the original request, and
days independent of the cache lifetime of the resource, and advertise expiring as a dictionary in 7 days independent of the cache lifetime
support for both sha-256 and sha-512 hash algorithms. of the resource.
2.1.5.2. Versioned Directories 2.1.6.2. Versioned Directories
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 main.js in any directory under /app/, expiring as a Would match main.js in any directory under /app/ and expiring as a
dictionary in one year and support using the sha-256 hash algorithm. dictionary in one year.
2.2. Available-Dictionary 2.2. Available-Dictionary
When a HTTP client makes a request for a resource for which it has an When a HTTP client makes a request for a resource for which it has an
appropriate dictionary, it can add a "Available-Dictionary" request appropriate dictionary, it can add a "Available-Dictionary" request
header to the request to indicate to the server that it has a 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 lowercase The "Available-Dictionary" request header is a Structured Field
Base16-encoded [RFC4648] hash of the contents of a single available [STRUCTURED-FIELDS] sf-binary [SHA-256] hash of the contents of a
dictionary calculated using one of the algorithms advertised as being single available dictionary.
supported by the server.
Its syntax is defined by the following [ABNF]:
Available-Dictionary = hvalue
hvalue = 1*hchar
hchar = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
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:
NOTE: '\' line wrapping per RFC 8792 Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Available-Dictionary: \
a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e
2.2.1. Dictionary freshness requirement 2.2.1. Dictionary freshness requirement
To be considered as a match, the dictionary must not yet be expired To be considered as a match, the dictionary must not yet be expired
as a dictionary. When iterating through dictionaries looking for a as a dictionary. When iterating through dictionaries looking for a
match, the expiration time of the dictionary is calculated by taking match, the expiration time of the dictionary is calculated by taking
the last time the dictionary was written and adding the "ttl" seconds the last time the dictionary was fetched and adding the "ttl" seconds
from the "Use-As-Dictionary" response. If the current time is beyond from the "Use-As-Dictionary" response. If the current time is beyond
the expiration time of the dictionary, it MUST be ignored. the expiration time of the dictionary, it MUST be ignored.
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 with the URL pattern of directive, it includes "match", "match-search" and "match-dest"
request URLs that the dictionary can be used for. strings that are used to match an outgoing request from a client to
the available dictionaries.
When comparing request URLs to the available dictionary match
patterns, the comparison should account for the * wildcard when
matching against request URLs. This can be accomplished with the
following algorithm which returns TRUE for a successful match and
FALSE for no-match:
1. Let MATCH represent the absolute URL pattern from the "match"
value for the given dictionary.
2. LET URL represent the request URL being checked.
3. If there are no * characters in MATCH: To see if an outbound request matches a given dictionary, the
following algorithm will return TRUE for a successful match and FALSE
for no-match:
* If the MATCH and URL strings are identical, return TRUE. 1. If the current client supports request destinations:
* Else, return FALSE. * Let DEST be the value of "match-dest" for the given
dictionary.
4. If there is a single * character in MATCH and it is at the end of * Let REQUEST_DEST be the value of the destination for the
the string: current request.
* If the MATCH string is identical to the start of the URL * If DEST is not an empty string and If DEST and REQUEST_DEST
string, return TRUE. are not the same value, return FALSE
* Else, return FALSE. 2. Let PATH be the value of "match" for the given dictionary.
5. Split the MATCH string by the * character into an array of 3. Let SEARCH be the value of "match-search" for the given
MATCHES (excluding the * deliminator from the individual dictionary.
entries).
6. If there is not a * character at the end of MATCH: 4. Let BASEURL be the request URL of the given dictionary.
* Pop the last entry in MATCHES from the end of the array into 5. Let PATTERN be a URLPattern constructed by setting pathname=PATH,
PATTERN. search=SEARCH, baseURL=BASEURL
(https://urlpattern.spec.whatwg.org/).
* If PATTERN is identical to the end of the URL string, remove 6. LET URL represent the request URL being checked.
the end of the URL string to the beginning of the match to
PATTERN.
* Else, return FALSE. 7. Return the result of running the URLPattern "match" algorithm
(https://urlpattern.spec.whatwg.org/#match)
7. Pop the first entry in MATCHES from the front of the array into 2.2.3. Multiple matching dictionaries
PATTERN.
* If PATTERN is not identical to the start of the URL string, When there are multiple dictionaries that match a given request URL,
return FALSE. the client MUST pick a single dictionary using the following rules:
1. For clients that support request destinations, a dictionary that
specifies and matches a "match-dest" takes precedence over a match
that does not use a destination. 1. Given equivalent destination
precedence, the dictionary with the longest "match" takes precedence.
1. Given equivalent destination and path precedence, the dictionary
with the longest "match-search" takes precedence. 1. Given
equivalent destination, path and search precedence, the most recently
fetched dictionary takes precedence.
8. Pop each entry off of the front of the MATCHES array into 2.3. Content-Dictionary
PATTERN. For each PATTERN, in order:
* Search for the first match of PATTERN in URL, starting from When a HTTP server responds with a resource that is encoded with a
the position of the end of the previous match. dictionary the server MUST send the hash of the dictionary that was
used in the "Content-Dictionary" response header.
* If no match is found, return FALSE. The "Content-Dictionary" response header is a Structured Field
[STRUCTURED-FIELDS] sf-dictionary [SHA-256] hash of the contents of
the dictionary that was used to encode the response.
9. Return TRUE. If the HTTP response contains a "Content-Dictionary" response header
with the hash of a dictionary that the client does not have available
then the client cannot decode or use the HTTP response.
2.2.3. Multiple matching dictionaries For example:
When there are multiple dictionaries that match a given request URL, Content-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
the client MUST pick the dictionary with the longest match pattern
string length.
3. Negotiating the compression algorithm 3. Negotiating the compression algorithm
When a compression dictionary is available for use for a given When a compression dictionary is available for use for a given
request, the algorithm to be used is negotiated through the regular request, the algorithm to be used is negotiated through the regular
mechanism for negotiating content encoding in HTTP. mechanism for negotiating content encoding in HTTP.
This document introduces two new content encoding algorithms: This document introduces two new content encoding algorithms:
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
skipping to change at page 9, line 27 skipping to change at page 9, line 27
IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field
Name Registry" registry ([HTTP]) according to the table below: Name Registry" registry ([HTTP]) 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 | Section 2.1 of this document |
| | | | | | | |
| Available-Dictionary | permanent | Section 2.2 of this document | | Available-Dictionary | permanent | Section 2.2 of this document |
| | | |
| Content-Dictionary | permanent | Section 2.3 of this document |
+----------------------+-----------+------------------------------+ +----------------------+-----------+------------------------------+
5. Compatibility Considerations 5. Compatibility Considerations
To minimize the risk of middle-boxes incorrectly processing To minimize the risk of middle-boxes incorrectly processing
dictionary-compressed responses, compression dictionary transport dictionary-compressed responses, compression dictionary transport
MUST only be used in secure contexts (HTTPS). MUST only be used in secure contexts (HTTPS).
6. Security Considerations 6. Security Considerations
The security considerations for Brotli [RFC7932] and Zstandard The security considerations for Brotli [RFC7932] and Zstandard
[RFC8878] apply to the dictionary-based versions of the respective [RFC8878] apply to the dictionary-based versions of the respective
algorithms. algorithms.
6.1. Changing content 6.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 to the decompressed content. change to the decompressed content.
The dictionary is validated using a SHA-256 hash of the content to
make sure 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 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 dictionary
negotiation should use a different hash algorithm, the "Use-As-
Dictionary" response header can be extended to specify a different
algorithm and the server would just ignore any "Available-Dictionary"
requests that do not use the updated hash.
6.2. Reading content 6.2. Reading content
The CRIME attack shows that it's a bad idea to compress data from The CRIME attack shows that it's a bad idea to compress data from
mixed (e.g. public and private) sources -- the data sources include mixed (e.g. public and private) sources -- the data sources include
not only the compressed data but also the dictionaries. For example, not only the compressed data but also the dictionaries. For example,
if you compress secret cookies using a public-data-only dictionary, if you compress secret cookies using a public-data-only dictionary,
you still leak information about the cookies. you still leak information about the cookies.
Not only can the dictionary reveal information about the compressed Not only can the dictionary reveal information about the compressed
data, but vice versa, data compressed with the dictionary can reveal data, but vice versa, data compressed with the dictionary can reveal
skipping to change at page 10, line 22 skipping to change at page 10, line 34
information about the compressed data. information about the compressed data.
6.3. Security Mitigations 6.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.
6.3.1. Cross-origin protection 6.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 "match" pattern used for origin where the dictionary was served, the URLPattern used for
matching a dictionary to requests MUST be for the same origin that matching a dictionary to requests is guaranteed to be for the same
the dictionary is served from. origin that the dictionary is served from.
6.3.2. Response readability 6.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
skipping to change at page 13, line 30 skipping to change at page 13, line 43
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[Origin] Barth, A., "The Web Origin Concept", RFC 6454, [Origin] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>. <https://www.rfc-editor.org/info/rfc6454>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[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/info/rfc7932>. <https://www.rfc-editor.org/info/rfc7932>.
[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/info/rfc8878>. <https://www.rfc-editor.org/info/rfc8878>.
[SHA-256] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[STRUCTURED-FIELDS] [STRUCTURED-FIELDS]
Nottingham, M. and P. Kamp, "Structured Field Values for Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/info/rfc8941>. <https://www.rfc-editor.org/info/rfc8941>.
[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/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
 End of changes. 50 change blocks. 
118 lines changed or deleted 136 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/