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: May 22, 2021 November 18, 2020
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 May 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 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. 6 change blocks. 
6 lines changed or deleted 6 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/