rfc9842v1.txt		rfc9842.txt
	Internet Engineering Task Force (IETF) P. Meenan, Ed.		Internet Engineering Task Force (IETF) P. Meenan, Ed.
	Request for Comments: 9842 Google LLC		Request for Comments: 9842 Google LLC
	Category: Standards Track Y. Weiss, Ed.		Category: Standards Track Y. Weiss, Ed.
	ISSN: 2070-1721 Shopify Inc		ISSN: 2070-1721 Shopify Inc
	August 2025		September 2025
	Compression Dictionary Transport		Compression Dictionary Transport
	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
	skipping to change at line 97 ¶		skipping to change at line 97 ¶
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	11.2. Informative References		11.2. Informative References
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	This specification defines a mechanism for using designated HTTP		This specification defines a mechanism for using designated HTTP
	[HTTP] responses as an external dictionary for future HTTP responses		[HTTP] responses as an external dictionary for future HTTP responses
	for compression schemes that support using external dictionaries		for compression schemes that support using external dictionaries
	(e.g., Brotli [RFC7932] and Zstandard [RFC8878]).		(e.g., Brotli [RFC7932] and Zstandard [ZSTD]).
	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
	skipping to change at line 245 ¶		skipping to change at line 245 ¶
	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 struct" created by running the
	create a URL pattern by setting input=MATCH and baseURL=URL (see		steps to "create a URL pattern" by setting input=MATCH and
	Part create of [URLPATTERN]).		baseURL=URL (see Section 1.4 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 the last list in
	groups of [URLPATTERN]).		Section 1.4 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		Dictionary" response header for the dictionary to be considered
	valid.		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" response header is
	List of String values that provides a list of Fetch request		an Inner 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 "RequestDestination" in
	of [FETCH]).		Section 5.4 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" response header is a String
	specifies a server identifier for the dictionary. If an "id" value		value that specifies a server identifier for the dictionary. If an
	is present and has a string length longer than zero, then it MUST be		"id" value is present and has a string length longer than zero, then
	sent to the server in a "Dictionary-ID" request header when the		it MUST be sent to the server in a "Dictionary-ID" request header
	client sends an "Available-Dictionary" request header for the same		when the client sends an "Available-Dictionary" request header for
	dictionary (see Section 2.2).		the same 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" response header is a
	that describes the file format of the supplied dictionary.		Token value that describes the file format of the supplied
			dictionary.
	"raw" is defined as a dictionary format that 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
	A response that contained a response header:		A response that contained a response header (as shown below) would
			specify matching any document request for a URL with a path prefix of
			/product/ on the same Origin (Section 4.3.1 of [HTTP]) as the
			original request:
	NOTE: '\' line wrapping per RFC 8792		NOTE: '\' line wrapping per RFC 8792
	Use-As-Dictionary: \		Use-As-Dictionary: \
	match="/product/*", match-dest=("document")		match="/product/*", match-dest=("document")
	Would specify matching any document request for a URL with a path
	prefix of /product/ on the same Origin (Section 4.3.1 of [HTTP]) as
	the original request.
	2.1.5.2. Versioned Directories		2.1.5.2. Versioned Directories
	A response that contained a response header:		A response that contained a response header (as shown below) would
			match any path that starts with "/app/" and ends with "/main.js":
	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
	"/main.js".
	2.2. Available-Dictionary		2.2. Available-Dictionary
	When an HTTP client makes a request for a resource for which it has		When an HTTP client makes a request for a resource for which it has
	an appropriate dictionary, it can add an "Available-Dictionary"		an appropriate dictionary, it can add an "Available-Dictionary"
	request 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 [SHA-256]		[STRUCTURED-FIELDS] Byte Sequence containing the SHA-256 [SHA-256]
	hash of the contents of a single available dictionary.		hash of the contents of a single available dictionary.
	skipping to change at line 397 ¶		skipping to change at line 395 ¶
	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 struct" created by running the
	create a URL pattern by setting input=MATCH and baseURL=URL (see		steps to "create a URL pattern" by setting input=MATCH and
	Part create of [URLPATTERN]).		baseURL=URL (see Section 1.4 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 "Match" in Section 1.4 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 an HTTP client makes a request for a resource for which it has		When an HTTP client makes a request for a resource for which it has
	an appropriate dictionary and the dictionary was stored with a		an appropriate dictionary and the dictionary was stored with a
	server-provided "id" in the Use-As-Dictionary response, the client		server-provided "id" in the "Use-As-Dictionary" response header, the
	MUST echo the stored "id" in a "Dictionary-ID" request header.		client 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 an 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
	skipping to change at line 458 ¶		skipping to change at line 457 ¶
	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 likely have the ability 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" response header and a caching response
	be usable as a compression dictionary. The link relation only		header for it to be usable as a compression dictionary. The link
	provides the mechanism for triggering the fetch of the dictionary.		relation only provides the mechanism for triggering the fetch of the
			dictionary.
	The following example shows a link to a resource at		The following example shows a link to a resource at
	https://example.org/dict.dat that is expected to produce a		https://example.org/dict.dat that is expected to produce a
	compression dictionary:		compression dictionary:
	Link: <https://example.org/dict.dat>; rel="compression-dictionary"		Link: <https://example.org/dict.dat>; rel="compression-dictionary"
	4. Dictionary-Compressed Brotli		4. Dictionary-Compressed Brotli
	The "dcb" content encoding identifies a resource that is a		The "dcb" content encoding identifies a resource that is a
	skipping to change at line 482 ¶		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 [SHARED-BROTLI].		prefix dictionary as defined in Section 8.2 of [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
	skipping to change at line 507 ¶		skipping to change at line 507 ¶
	allowing for delta-compression of resources larger than the		allowing for delta-compression of resources larger than the
	compression window.		compression window.
	5. Dictionary-Compressed Zstandard		5. Dictionary-Compressed Zstandard
	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		[ZSTD] 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 [RFC8878].		dictionary as per Section 5 of [ZSTD].
	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].
	skipping to change at line 549 ¶		skipping to change at line 549 ¶
	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 to compress the response
	response to a given request, the encoding to be used is negotiated		to a given request, the encoding to be used is negotiated through the
	through the regular mechanism for negotiating content encoding in		regular mechanism for negotiating content encoding in HTTP through
	HTTP through the "Accept-Encoding" request header and "Content-		the "Accept-Encoding" request header and "Content-Encoding" response
	Encoding" response header.		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. For example:		supports to the "Accept-Encoding" request header. For example:
	skipping to change at line 646 ¶		skipping to change at line 646 ¶
	It is not unusual for devices to be 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,		intercept, inspect, and process HTTP requests (web proxies,
	firewalls, intrusion detection systems, etc.). To minimize the risk		firewalls, intrusion detection systems, etc.). To minimize the risk
	of these devices incorrectly processing dictionary-compressed		of these devices incorrectly processing dictionary-compressed
	responses, compression dictionary transport MUST only be used in		responses, compression dictionary transport MUST only be used in
	secure contexts (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-		[SHARED-BROTLI], and Zstandard [ZSTD] apply to the dictionary-based
	based versions of the respective algorithms.		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 change		the content because a change to the dictionary can result in a change
	to the decompressed content.		to the decompressed content.
	The dictionary is validated using an 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
	skipping to change at line 706 ¶		skipping to change at line 706 ¶
	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 either the dictionary and compressed
	context they are being fetched from or that the response is cross-		response are same-origin to the context they are being fetched from
	origin and passes the Cross-Origin Resource Sharing (CORS) check (see		or the response is cross-origin and passes the Cross-Origin Resource
	Part CORS check of [FETCH]).		Sharing (CORS) check (see Section 4.9 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
	skipping to change at line 771 ¶		skipping to change at line 771 ¶
	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 using partitioning similar to or
	as clearing the dictionaries whenever cookies are cleared.		stricter than the partitioning used for cookies, as well as clearing
			the dictionaries whenever cookies are cleared.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[FETCH] WHATWG, "Fetch Standard", WHATWG Living Standard,		[FETCH] WHATWG, "Fetch Standard", WHATWG Living Standard,
	<https://fetch.spec.whatwg.org/>. Commit snapshot:		<https://fetch.spec.whatwg.org/>. Commit snapshot:
	<https://fetch.spec.whatwg.org/commit-		<https://fetch.spec.whatwg.org/commit-
	snapshots/5a9680638ebfc2b3b7f4efb2bef0b579a2663951/>		snapshots/5a9680638ebfc2b3b7f4efb2bef0b579a2663951/>
	skipping to change at line 808 ¶		skipping to change at line 809 ¶
	[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/info/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/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
	and the 'application/zstd' Media Type", RFC 8878,
	DOI 10.17487/RFC8878, February 2021,
	<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/info/rfc6234>.		<https://www.rfc-editor.org/info/rfc6234>.
	[SHARED-BROTLI]		[SHARED-BROTLI]
	Alakuijala, J., Duong, T., Kliuchnikov, E., Szabadka, Z.,		Alakuijala, J., Duong, T., Kliuchnikov, E., Szabadka, Z.,
	and L. Vandevenne, "Shared Brotli Compressed Data Format",		and L. Vandevenne, "Shared Brotli Compressed Data Format",
	RFC 9841, DOI 10.17487/RFC9841, August 2025,		RFC 9841, DOI 10.17487/RFC9841, September 2025,
	<https://www.rfc-editor.org/info/rfc9841>.		<https://www.rfc-editor.org/info/rfc9841>.
	[STRUCTURED-FIELDS]		[STRUCTURED-FIELDS]
	Nottingham, M. and P. Kamp, "Structured Field Values for		Nottingham, M. and P. Kamp, "Structured Field Values for
	HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,		HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
	<https://www.rfc-editor.org/info/rfc9651>.		<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,
	skipping to change at line 845 ¶		skipping to change at line 841 ¶
	WHATWG, "URL Pattern Standard", WHATWG Living Standard,		WHATWG, "URL Pattern Standard", WHATWG Living Standard,
	<https://urlpattern.spec.whatwg.org/>. Commit snapshot:		<https://urlpattern.spec.whatwg.org/>. Commit snapshot:
	<https://urlpattern.spec.whatwg.org/commit-		<https://urlpattern.spec.whatwg.org/commit-
	snapshots/696b4029d52e5854044bac6b72cdb198cb962ed0/>		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/info/rfc8288>.		<https://www.rfc-editor.org/info/rfc8288>.
			[ZSTD] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
			and the 'application/zstd' Media Type", RFC 8878,
			DOI 10.17487/RFC8878, February 2021,
			<https://www.rfc-editor.org/info/rfc8878>.
	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/info/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/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
End of changes. 25 change blocks.
	59 lines changed or deleted		60 lines changed or added
This html diff was produced by rfcdiff 1.48.