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 24, 2025 Shopify Inc | |||
August 28, 2024 | November 20, 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 24, 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/ |