draft-ietf-httpbis-compression-dictionary-19.txt   draft-ietf-httpbis-compression-dictionary-latest.txt 
HTTP Working Group P. Meenan, Ed. HTTP Working Group P. Meenan, Ed.
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Standards Track Y. Weiss, Ed. Intended status: Standards Track Y. Weiss, Ed.
Expires: March 1, 2025 Shopify Inc Expires: May 20, 2025 Shopify Inc
August 28, 2024 November 16, 2024
Compression Dictionary Transport Compression Dictionary Transport
draft-ietf-httpbis-compression-dictionary-19 draft-ietf-httpbis-compression-dictionary-latest
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.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 1, 2025. This Internet-Draft will expire on May 20, 2025.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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 6, line 44 skipping to change at page 6, line 44
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
Section create of [URLPATTERN]). Section "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 Section has regexp PATTERN returns TRUE then return FALSE (see Section "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/duesseldorf" would be For example the URL "http://www.example.com/duesseldorf" 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 destinations for the dictionary to match (see Section "destination"
Appendix 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
skipping to change at page 10, line 7 skipping to change at page 10, line 7
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
Section create of [URLPATTERN]). Section "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 Section match of and the supplied "match" string (see Section "match" of
[URLPATTERN]). [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.
skipping to change at page 17, line 7 skipping to change at page 17, line 7
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 Appendix CORS check of origin and passes the CORS check (see Section "CORS check" of
[FETCH]). [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
 End of changes. 9 change blocks. 
12 lines changed or deleted 12 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/