draft-ietf-httpbis-client-hints-15.txt		draft-ietf-httpbis-client-hints-latest.txt
	HTTP Working Group I. Grigorik		HTTP Working Group I. Grigorik
	Internet-Draft Y. Weiss		Internet-Draft Y. Weiss
	Intended status: Experimental Google		Intended status: Experimental Google
	Expires: January 4, 2021 July 3, 2020		Expires: April 16, 2026 October 13, 2025
	HTTP Client Hints		HTTP Client Hints
	draft-ietf-httpbis-client-hints-15		draft-ietf-httpbis-client-hints-latest
	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
	sending them impacts both performance and privacy.		sending them impacts both performance and privacy.
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 January 4, 2021.		This Internet-Draft will expire on April 16, 2026.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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 9 ¶		skipping to change at page 6, line 9 ¶
	Accept-CH is a Structured Header [I-D.ietf-httpbis-header-structure].		Accept-CH is a Structured Header [I-D.ietf-httpbis-header-structure].
	Its value MUST be an sf-list (Section 3.1 of		Its value MUST be an sf-list (Section 3.1 of
	[I-D.ietf-httpbis-header-structure]) whose members are tokens		[I-D.ietf-httpbis-header-structure]) whose members are tokens
	(Section 3.3.4 of [I-D.ietf-httpbis-header-structure]). Its ABNF is:		(Section 3.3.4 of [I-D.ietf-httpbis-header-structure]). Its ABNF is:
	Accept-CH = sf-list		Accept-CH = sf-list
	For example:		For example:
	Accept-CH: Sec-CH-Example, Sec-CH-Example-2		Accept-CH: Sec-CH-Example, Sec-CH-Example-2
	When a user agent receives an HTTP response containing "Accept-CH",		When a user agent receives an HTTP response containing "Accept-CH",
	that indicates that the origin opts-in to receive the indicated		that indicates that the origin opts-in to receive the indicated
	request header fields for subsequent same-origin requests. The opt-		request header fields for subsequent same-origin requests. The opt-
	in MUST be ignored if delivered over non-secure transport (using a		in MUST be ignored if delivered over non-secure transport (using a
	scheme different from HTTPS). It SHOULD be persisted and bound to		scheme different from HTTPS). It SHOULD be persisted and bound to
	the origin to enable delivery of Client Hints on subsequent requests		the origin to enable delivery of Client Hints on subsequent requests
	to the server's origin, for the duration of the user's session (as		to the server's origin, for the duration of the user's session (as
	defined by the user agent). An opt-in overrides previous persisted		defined by the user agent). An opt-in overrides previous persisted
	opt-in values and SHOULD be persisted in its stead.		opt-in values and SHOULD be persisted in its stead.
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 43 ¶
	"https://other.example/").		"https://other.example/").
	3.2. Interaction with Caches		3.2. Interaction with Caches
	When selecting a response based on one or more Client Hints, and if		When selecting a response based on one or more Client Hints, and if
	the resource is cacheable, the server needs to generate a Vary		the resource is cacheable, the server needs to generate a Vary
	response header field ([RFC7234]) to indicate which hints can affect		response header field ([RFC7234]) to indicate which hints can affect
	the selected response and whether the selected response is		the selected response and whether the selected response is
	appropriate for a later request.		appropriate for a later request.
	Vary: Sec-CH-Example		Vary: Sec-CH-Example
	The above example indicates that the cache key needs to include the		The above example indicates that the cache key needs to include the
	Sec-CH-Example header field.		Sec-CH-Example header field.
	Vary: Sec-CH-Example, Sec-CH-Example-2		Vary: Sec-CH-Example, Sec-CH-Example-2
	The above example indicates that the cache key needs to include the		The above example indicates that the cache key needs to include the
	Sec-CH-Example and Sec-CH-Example-2 header fields.		Sec-CH-Example and Sec-CH-Example-2 header fields.
	4. Security Considerations		4. Security Considerations
	4.1. Information Exposure		4.1. Information Exposure
	Request header fields used in features relying on this document		Request header fields used in features relying on this document
	expose information about the user's environment to enable privacy-		expose information about the user's environment to enable privacy-
End of changes. 7 change blocks.
	7 lines changed or deleted		7 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/