draft-ietf-httpbis-no-vary-search-03.txt		draft-ietf-httpbis-no-vary-search-latest.txt
	HyperText Transfer Protocol		HyperText Transfer Protocol
	Internet-Draft		Internet-Draft
	Intended status: Standards Track Google LLC		Intended status: Standards Track Google LLC
	Expires: April 2, 2026 September 29, 2025		Expires: April 26, 2026 October 23, 2025
	The No-Vary-Search HTTP Response Header Field		The No-Vary-Search HTTP Response Header Field
	draft-ietf-httpbis-no-vary-search-03		draft-ietf-httpbis-no-vary-search-latest
	Abstract		Abstract
	This specification defines a proposed HTTP response header field for		This specification defines a proposed HTTP response header field for
	changing how URL search parameters impact caching.		changing how URL search parameters impact caching.
	About This Document		About This Document
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 April 2, 2026.		This Internet-Draft will expire on April 26, 2026.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 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
	skipping to change at page 3, line 31 ¶		skipping to change at page 3, line 31 ¶
	indicated using		indicated using
	No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign")		No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign")
	And if the resource instead wants to take an allowlist-based		And if the resource instead wants to take an allowlist-based
	approach, where only certain known query parameters semantically		approach, where only certain known query parameters semantically
	affect the served resource, they can use		affect the served resource, they can use
	No-Vary-Search: params, except=("productId")		No-Vary-Search: params, except=("productId")
	Section 3 defines the header, using the [STRUCTURED-FIELDS]		Section 3 defines the header field, using the [STRUCTURED-FIELDS]
	framework. Section 4 and Section 5 illustrate the data model for how		framework. Section 4 and Section 5 illustrate the data model for how
	the header can be represented in specifications, and the process for		the field value can be represented in specifications, and the process
	parsing the raw output from the structured field parser into that		for parsing the raw output from the structured field parser into that
	data model. Section 6 gives the key algorithm for comparing if two		data model. Section 6 gives the key algorithm for comparing if two
	URLs are equivalent under the influence of the header; notably, it		URLs are equivalent under the influence of the header field; notably,
	leans on the decomposition of the query component into keys and		it leans on the decomposition of the query component into keys and
	values given by the application/x-www-form-urlencoded [1] format		values given by the application/x-www-form-urlencoded [1] format
	specified in [WHATWG-URL]. (As such, this header is not useful for		specified in [WHATWG-URL]. (As such, this header field is not useful
	URLs whose query component does not follow that format.) Finally,		for URLs whose query component does not follow that format.)
	Section 7 explains how to modify [HTTP-CACHING] to take into account		Finally, Section 7 explains how to modify [HTTP-CACHING] to take into
	this new equivalence.		account this new equivalence.
	2. Conventions and Definitions		2. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This document also adopts some conventions and notation typical in		This document also adopts some conventions and notation typical in
	skipping to change at page 11, line 15 ¶		skipping to change at page 11, line 15 ¶
	+---------------------------------+---------------------------------+		+---------------------------------+---------------------------------+
	| Input | Conventional form |		| Input | Conventional form |
	+---------------------------------+---------------------------------+		+---------------------------------+---------------------------------+
	| "No-Vary-Search: params=?1" | "No-Vary-Search: params" |		| "No-Vary-Search: params=?1" | "No-Vary-Search: params" |
	| | |		| | |
	| "No-Vary-Search: key-order=?1" | "No-Vary-Search: key-order" |		| "No-Vary-Search: key-order=?1" | "No-Vary-Search: key-order" |
	| | |		| | |
	| "No-Vary-Search: params, key- | "No-Vary-Search: key-order, |		| "No-Vary-Search: params, key- | "No-Vary-Search: key-order, |
	| order, except=("x")" | params, except=("x")" |		| order, except=("x")" | params, except=("x")" |
	| | |		| | |
	| "No-Vary-Search: params=?0" | (omit the header) |		| "No-Vary-Search: params=?0" | (omit the header field) |
	| | |		| | |
	| "No-Vary-Search: params=()" | (omit the header) |		| "No-Vary-Search: params=()" | (omit the header field) |
	| | |		| | |
	| "No-Vary-Search: key-order=?0" | (omit the header) |		| "No-Vary-Search: key-order=?0" | (omit the header field) |
	+---------------------------------+---------------------------------+		+---------------------------------+---------------------------------+
	5.3. Parse a key		5.3. Parse a key
	To parse a key given an ASCII string _keyString_:		To parse a key given an ASCII string _keyString_:
	1. Let _keyBytes_ be the isomorphic encoding [4] [WHATWG-INFRA] of		1. Let _keyBytes_ be the isomorphic encoding [4] [WHATWG-INFRA] of
	_keyString_.		_keyString_.
	2. Replace any 0x2B (+) in _keyBytes_ with 0x20 (SP).		2. Replace any 0x2B (+) in _keyBytes_ with 0x20 (SP).
	skipping to change at page 12, line 8 ¶		skipping to change at page 12, line 8 ¶
	_keyBytes_.		_keyBytes_.
	4. Let _keyStringDecoded_ be the UTF-8 decoding without BOM [6]		4. Let _keyStringDecoded_ be the UTF-8 decoding without BOM [6]
	[WHATWG-ENCODING] of _keyBytesDecoded_.		[WHATWG-ENCODING] of _keyBytesDecoded_.
	5. Return _keyStringDecoded_.		5. Return _keyStringDecoded_.
	5.3.1. Examples		5.3.1. Examples
	The parse a key algorithm allows encoding non-ASCII key strings in		The parse a key algorithm allows encoding non-ASCII key strings in
	the ASCII structured header format, similar to how the application/x-		the ASCII structured header field format, similar to how the
	www-form-urlencoded [7] format [WHATWG-URL] allows encoding an entire		application/x-www-form-urlencoded [7] format [WHATWG-URL] allows
	entry list of keys and values in ASCII URL format. For example,		encoding an entire entry list of keys and values in ASCII URL format.
			For example,
	No-Vary-Search: params=("%C3%A9+%E6%B0%97")		No-Vary-Search: params=("%C3%A9+%E6%B0%97")
	will result in a URL search variance whose vary params are << ""e		will result in a URL search variance whose vary params are << ""e
	&#27671;"" >>. As explained in a later example, the canonicalization		&#27671;"" >>. As explained in a later example, the canonicalization
	process during equivalence testing means this will treat as		process during equivalence testing means this will treat as
	equivalent URL strings such as:		equivalent URL strings such as:
	o "https://example.com/?e &#27671;=1"		o "https://example.com/?e &#27671;=1"
	skipping to change at page 19, line 7 ¶		skipping to change at page 19, line 7 ¶
	does not have privacy impacts. It does not interfere with existing		does not have privacy impacts. It does not interfere with existing
	navigational tracking mitigations [21], or any known future ones		navigational tracking mitigations [21], or any known future ones
	being contemplated. Indeed, if a page were to encode user		being contemplated. Indeed, if a page were to encode user
	identifiers in its URL, the only ability this proposal gives is to		identifiers in its URL, the only ability this proposal gives is to
	_reduce_ such user tracking by preventing server processing of such		_reduce_ such user tracking by preventing server processing of such
	user IDs (since the server is bypassed in favor of the cache).		user IDs (since the server is bypassed in favor of the cache).
	[NAV-TRACKING-MITIGATIONS]		[NAV-TRACKING-MITIGATIONS]
	10. IANA Considerations		10. IANA Considerations
	IANA should do the following:
	10.1. HTTP Field Names		10.1. HTTP Field Names
	Enter the following into the Hypertext Transfer Protocol (HTTP) Field		IANA is requested to enter the following into the Hypertext Transfer
	Name Registry:		Protocol (HTTP) Field Name Registry
			(https://www.iana.org/assignments/http-fields/http-fields.xhtml
			[22]):
	Field Name "No-Vary-Search"		Field Name: "No-Vary-Search"
	Status permanent		Status: permanent
	Structured Type Dictionary		Structured Type: Dictionary
	Reference this document		Reference: this document
	Comments (none)		Comments: (none)
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[FETCH] van Kesteren, A., "Fetch Living Standard", n.d.,		[FETCH] van Kesteren, A., "Fetch Living Standard", n.d.,
	<https://fetch.spec.whatwg.org/>.		<https://fetch.spec.whatwg.org/>.
	WHATWG		WHATWG
	skipping to change at page 20, line 7 ¶		skipping to change at page 20, line 7 ¶
	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>.
	[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 9651, DOI 10.17487/RFC9651, September 2024,
	<https://www.rfc-editor.org/info/rfc8941>.		<https://www.rfc-editor.org/info/rfc9651>.
	[WHATWG-ENCODING]		[WHATWG-ENCODING]
	van Kesteren, A., "Encoding Living Standard", n.d.,		van Kesteren, A., "Encoding Living Standard", n.d.,
	<https://encoding.spec.whatwg.org/>.		<https://encoding.spec.whatwg.org/>.
	WHATWG		WHATWG
	[WHATWG-INFRA]		[WHATWG-INFRA]
	van Kesteren, A. and D. Denicola, "Infra Living Standard",		van Kesteren, A. and D. Denicola, "Infra Living Standard",
	n.d., <https://infra.spec.whatwg.org/>.		n.d., <https://infra.spec.whatwg.org/>.
	skipping to change at page 21, line 43 ¶		skipping to change at page 21, line 43 ¶
	[19] https://html.spec.whatwg.org/multipage/nav-history-		[19] https://html.spec.whatwg.org/multipage/nav-history-
	apis.html#dom-history-replacestate		apis.html#dom-history-replacestate
	[20] https://privacycg.github.io/nav-tracking-		[20] https://privacycg.github.io/nav-tracking-
	mitigations/#terminology		mitigations/#terminology
	[21] https://privacycg.github.io/nav-tracking-mitigations/#deployed-		[21] https://privacycg.github.io/nav-tracking-mitigations/#deployed-
	mitigations		mitigations
			[22] https://www.iana.org/assignments/http-fields/http-fields.xhtml
	Index		Index
	D		D
	default URL search variance 5-9, 12		default URL search variance 5-9, 12
	E		E
	equivalent modulo search variance 12		equivalent modulo search variance 12
	O		O
	obtain a URL search variance 5, 9		obtain a URL search variance 5, 9
End of changes. 20 change blocks.
	29 lines changed or deleted		32 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/