Diff: rfc8942v3.txt - rfc8942.txt

	rfc8942v3.txt	rfc8942.txt

	Internet Engineering Task Force (IETF) I. Grigorik	Internet Engineering Task Force (IETF) I. Grigorik
	Request for Comments: 8942 Y. Weiss	Request for Comments: 8942 Y. Weiss
	Category: Experimental Google	Category: Experimental Google

	ISSN: 2070-1721 October 2020	ISSN: 2070-1721 January 2021

	HTTP Client Hints	HTTP Client Hints

	Abstract	Abstract

	HTTP defines proactive content negotiation to allow servers to select	HTTP defines proactive content negotiation to allow servers to select
	the appropriate response for a given request, based upon the user	the appropriate response for a given request, based upon the user
	agent's characteristics, as expressed in request headers. In	agent's characteristics, as expressed in request headers. In
	practice, user agents are often unwilling to send those request	practice, user agents are often unwilling to send those request
	headers, because it is not clear whether they will be used, and	headers, because it is not clear whether they will be used, and

	skipping to change at line 43 ¶	skipping to change at line 43 ¶
	publication by the Internet Engineering Steering Group (IESG). Not	publication by the Internet Engineering Steering Group (IESG). Not
	all documents approved by the IESG are candidates for any level of	all documents approved by the IESG are candidates for any level of
	Internet Standard; see Section 2 of RFC 7841.	Internet Standard; see Section 2 of RFC 7841.

	Information about the current status of this document, any errata,	Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at	and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc8942.	https://www.rfc-editor.org/info/rfc8942.

	Copyright Notice	Copyright Notice


	Copyright (c) 2020 IETF Trust and the persons identified as the	Copyright (c) 2021 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 line 84 ¶	skipping to change at line 84 ¶
	7.1. Normative References	7.1. Normative References
	7.2. Informative References	7.2. Informative References
	Acknowledgements	Acknowledgements
	Authors' Addresses	Authors' Addresses

	1. Introduction	1. Introduction

	There are thousands of different devices accessing the web, each with	There are thousands of different devices accessing the web, each with
	different device capabilities and preference information. These	different device capabilities and preference information. These
	device capabilities include hardware and software characteristics, as	device capabilities include hardware and software characteristics, as

	well as dynamic user and user-agent preferences. Historically,	well as dynamic user and user agent preferences. Historically,
	applications that wanted the server to optimize content delivery and	applications that wanted the server to optimize content delivery and
	user experience based on such capabilities had to rely on passive	user experience based on such capabilities had to rely on passive
	identification (e.g., by matching the User-Agent header field	identification (e.g., by matching the User-Agent header field

	(Section 5.5.3 of [RFC7231]) against an established database of user-	(Section 5.5.3 of [RFC7231]) against an established database of user
	agent signatures), use HTTP cookies [RFC6265] and URL parameters, or	agent signatures), use HTTP cookies [RFC6265] and URL parameters, or
	use some combination of these and similar mechanisms to enable ad hoc	use some combination of these and similar mechanisms to enable ad hoc
	content negotiation.	content negotiation.

	Such techniques are expensive to set up and maintain and are not	Such techniques are expensive to set up and maintain and are not
	portable across both applications and servers. They also make it	portable across both applications and servers. They also make it
	hard for both user agent and server to understand which data are	hard for both user agent and server to understand which data are
	required and are in use during the negotiation:	required and are in use during the negotiation:


	* User-agent detection cannot reliably identify all static	* User agent detection cannot reliably identify all static
	variables, cannot infer dynamic user-agent preferences, requires	variables, cannot infer dynamic user agent preferences, requires
	an external device database, is not cache friendly, and is reliant	an external device database, is not cache friendly, and is reliant
	on a passive fingerprinting surface.	on a passive fingerprinting surface.
	* Cookie-based approaches are not portable across applications and	* Cookie-based approaches are not portable across applications and
	servers, impose additional client-side latency by requiring	servers, impose additional client-side latency by requiring
	JavaScript execution, and are not cache friendly.	JavaScript execution, and are not cache friendly.
	* URL parameters, similar to cookie-based approaches, suffer from	* URL parameters, similar to cookie-based approaches, suffer from
	lack of portability and are hard to deploy due to a requirement to	lack of portability and are hard to deploy due to a requirement to
	encode content negotiation data inside of the URL of each	encode content negotiation data inside of the URL of each
	resource.	resource.


	skipping to change at line 174 ¶	skipping to change at line 174 ¶
	User agents choose what Client Hints to send in a request based on	User agents choose what Client Hints to send in a request based on
	their default settings, user configuration, and server preferences	their default settings, user configuration, and server preferences
	expressed in "Accept-CH". The user agent and server can use an opt-	expressed in "Accept-CH". The user agent and server can use an opt-
	in mechanism outlined below to negotiate which header fields need to	in mechanism outlined below to negotiate which header fields need to
	be sent to allow for efficient content adaption, and they can	be sent to allow for efficient content adaption, and they can
	optionally use additional mechanisms (e.g., as outlined in	optionally use additional mechanisms (e.g., as outlined in
	[CLIENT-HINTS-INFRASTRUCTURE]) to negotiate delegation policies that	[CLIENT-HINTS-INFRASTRUCTURE]) to negotiate delegation policies that
	control access of third parties to those same header fields. User	control access of third parties to those same header fields. User
	agents SHOULD require an opt-in to send any hints that are not	agents SHOULD require an opt-in to send any hints that are not
	considered low-entropy. See the low-entropy hint table at	considered low-entropy. See the low-entropy hint table at

	[CLIENT-HINTS-INFRASTRUCTURE] for examples of ones that are.	[CLIENT-HINTS-INFRASTRUCTURE] for examples of hints that expose low
		amounts of entropy.

	Implementers need to be aware of the fingerprinting implications when	Implementers need to be aware of the fingerprinting implications when
	implementing support for Client Hints and follow the considerations	implementing support for Client Hints and follow the considerations
	outlined in the Security Considerations section of this document (see	outlined in the Security Considerations section of this document (see
	Section 4).	Section 4).

	2.2. Server Processing of Client Hints	2.2. Server Processing of Client Hints

	When presented with a request that contains one or more Client Hints	When presented with a request that contains one or more Client Hints
	header fields, servers can optimize the response based upon the	header fields, servers can optimize the response based upon the

	skipping to change at line 207 ¶	skipping to change at line 208 ¶
	values to aid client processing.	values to aid client processing.

	3. Advertising Server Support	3. Advertising Server Support

	Servers can advertise support for Client Hints using the mechanism	Servers can advertise support for Client Hints using the mechanism
	described below.	described below.

	3.1. The Accept-CH Response Header Field	3.1. The Accept-CH Response Header Field

	The Accept-CH response header field indicates server support for the	The Accept-CH response header field indicates server support for the

	hints indicated in its value. Servers wishing to receive user-agent	hints indicated in its value. Servers wishing to receive user agent
	information through Client Hints SHOULD add the Accept-CH response	information through Client Hints SHOULD add the Accept-CH response
	header to their responses as early as possible.	header to their responses as early as possible.

	Accept-CH is a Structured Header [RFC8941]. Its value MUST be an sf-	Accept-CH is a Structured Header [RFC8941]. Its value MUST be an sf-
	list (Section 3.1 of [RFC8941]) whose members are Tokens	list (Section 3.1 of [RFC8941]) whose members are Tokens
	(Section 3.3.4 of [RFC8941]). Its ABNF is:	(Section 3.3.4 of [RFC8941]). Its ABNF is:

	Accept-CH = sf-list	Accept-CH = sf-list

	For example:	For example:

	skipping to change at line 331 ¶	skipping to change at line 332 ¶
	application, but gated behind specific user actions (e.g., a	application, but gated behind specific user actions (e.g., a
	permission prompt or user activation), SHOULD NOT be exposed as a	permission prompt or user activation), SHOULD NOT be exposed as a
	Client Hint.	Client Hint.

	Change over time: The feature SHOULD NOT expose user information	Change over time: The feature SHOULD NOT expose user information
	that changes over time, unless the state change itself is also	that changes over time, unless the state change itself is also
	exposed (e.g., through JavaScript callbacks).	exposed (e.g., through JavaScript callbacks).

	Different features will be positioned in different points in the	Different features will be positioned in different points in the
	space between low-entropy, non-sensitive, and static information	space between low-entropy, non-sensitive, and static information

	(e.g., user-agent information) and high-entropy, sensitive, and	(e.g., user agent information) and high-entropy, sensitive, and
	dynamic information (e.g., geolocation). User agents need to	dynamic information (e.g., geolocation). User agents need to
	consider the value provided by a particular feature vs. these	consider the value provided by a particular feature vs. these
	considerations and may wish to have different policies regarding that	considerations and may wish to have different policies regarding that
	tradeoff on a per-feature or other fine-grained basis.	tradeoff on a per-feature or other fine-grained basis.

	Implementers ought to consider both user- and server-controlled	Implementers ought to consider both user- and server-controlled
	mechanisms and policies to control which Client Hints header fields	mechanisms and policies to control which Client Hints header fields
	are advertised:	are advertised:

	* Implementers SHOULD restrict delivery of some or all Client Hints	* Implementers SHOULD restrict delivery of some or all Client Hints

	skipping to change at line 470 ¶	skipping to change at line 471 ¶
	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	RFC 7234, DOI 10.17487/RFC7234, June 2014,	RFC 7234, DOI 10.17487/RFC7234, June 2014,
	<https://www.rfc-editor.org/info/rfc7234>.	<https://www.rfc-editor.org/info/rfc7234>.

	[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>.

	[RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for	[RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for

	HTTP", RFC 8941, DOI 10.17487/RFC8941, October 2020,	HTTP", RFC 8941, DOI 10.17487/RFC8941, January 2021,
	<https://www.rfc-editor.org/info/rfc8941>.	<https://www.rfc-editor.org/info/rfc8941>.

	7.2. Informative References	7.2. Informative References

	[CLIENT-HINTS-INFRASTRUCTURE]	[CLIENT-HINTS-INFRASTRUCTURE]
	Weiss, Y., "Client Hints Infrastructure", July 2020,	Weiss, Y., "Client Hints Infrastructure", July 2020,
	<https://wicg.github.io/client-hints-infrastructure/>.	<https://wicg.github.io/client-hints-infrastructure/>.

	[FETCH] WHATWG, "Fetch - Living Standard", Living Standard,	[FETCH] WHATWG, "Fetch - Living Standard", Living Standard,
	September 2020, <https://fetch.spec.whatwg.org/>.	September 2020, <https://fetch.spec.whatwg.org/>.

End of changes. 9 change blocks.
	10 lines changed or deleted	11 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/