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: April 28, 2026 Shopify Inc
	August 28, 2024		October 25, 2025
	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 April 28, 2026.
	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		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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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
	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. 10 change blocks.
	13 lines changed or deleted		13 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/