draft-ietf-httpbis-client-hints-00.txt   draft-ietf-httpbis-client-hints-01.txt 
HTTP Working Group I. Grigorik HTTP Working Group I. Grigorik
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track November 24, 2015 Intended status: Standards Track May 31, 2016
Expires: May 27, 2016 Expires: December 2, 2016
HTTP Client Hints HTTP Client Hints
draft-ietf-httpbis-client-hints-00 draft-ietf-httpbis-client-hints-01
Abstract Abstract
An increasing diversity of Web-connected devices and software An increasing diversity of Web-connected devices and software
capabilities has created a need to deliver optimized content for each capabilities has created a need to deliver optimized content for each
device. device.
This specification defines a set of HTTP request header fields, This specification defines a set of HTTP request header fields,
colloquially known as Client Hints, to address this. They are colloquially known as Client Hints, to address this. They are
intended to be used as input to proactive content negotiation; just intended to be used as input to proactive content negotiation; just
as the Accept header allows clients to indicate what formats they as the Accept header field allows clients to indicate what formats
prefer, Client Hints allow clients to indicate a list of device and they prefer, Client Hints allow clients to indicate a list of device
agent specific preferences. and agent specific preferences.
Note to Readers Note to Readers
The issues list for this draft can be found at Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ .
Working Group information can be found at http://httpwg.github.io/ ;
source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/client-hints . https://github.com/httpwg/http-extensions/labels/client-hints .
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 27, 2016. This Internet-Draft will expire on December 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Client Hint Request Header Fields . . . . . . . . . . . . . . 3 2. Client Hint Request Header Fields . . . . . . . . . . . . . . 4
2.1. Sending Client Hints . . . . . . . . . . . . . . . . . . 4 2.1. Sending Client Hints . . . . . . . . . . . . . . . . . . 4
2.2. Server Processing of Client Hints . . . . . . . . . . . . 4 2.2. Server Processing of Client Hints . . . . . . . . . . . . 4
2.2.1. Advertising Support for Client Hints . . . . . . . . 4 2.2.1. Advertising Support for Client Hints . . . . . . . . 4
2.2.2. Interaction with Caches . . . . . . . . . . . . . . . 5 2.2.2. Interaction with Caches . . . . . . . . . . . . . . . 5
3. The DPR Client Hint . . . . . . . . . . . . . . . . . . . . . 6 3. The DPR Client Hint . . . . . . . . . . . . . . . . . . . . . 6
3.1. Confirming Selected DPR . . . . . . . . . . . . . . . . . 6 3.1. Confirming Selected DPR . . . . . . . . . . . . . . . . . 6
4. The Width Client Hint . . . . . . . . . . . . . . . . . . . . 6 4. The Width Client Hint . . . . . . . . . . . . . . . . . . . . 7
5. The Viewport-Width Client Hint . . . . . . . . . . . . . . . 7 5. The Viewport-Width Client Hint . . . . . . . . . . . . . . . 7
6. The Downlink Client Hint . . . . . . . . . . . . . . . . . . 7 6. The Downlink Client Hint . . . . . . . . . . . . . . . . . . 7
7. The Save-Data Hint . . . . . . . . . . . . . . . . . . . . . 7 7. The Save-Data Client Hint . . . . . . . . . . . . . . . . . . 7
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . 10 10.1. Accept-CH . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 10.2. Content-DPR . . . . . . . . . . . . . . . . . . . . . . 9
10.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 10
10.4. DPR . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.5. Save-Data . . . . . . . . . . . . . . . . . . . . . . . 10
10.6. Viewport-Width . . . . . . . . . . . . . . . . . . . . . 10
10.7. Width . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 12
A.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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 client preferences. well as dynamic user and client preferences.
One way to infer some of these capabilities is through User-Agent One way to infer some of these capabilities is through User-Agent
(UA) detection against an established database of client signatures. (UA; Section 5.5.3 of [RFC7231]) detection against an established
However, this technique requires acquiring such a database, database of client signatures. However, this technique requires
integrating it into the serving path, and keeping it up to date. acquiring such a database, integrating it into the serving path, and
keeping it up to date. However, even once this infrastructure is
However, even once this infrastructure is deployed, UA sniffing has deployed, UA sniffing has numerous limitations:
numerous limitations:
o UA detection cannot reliably identify all static variables o UA detection cannot reliably identify all static variables
o UA detection cannot infer any dynamic client preferences o UA detection cannot infer any dynamic client preferences
o UA detection requires an external device database o UA detection requires an external device database
o UA detection is not cache friendly o UA detection is not cache friendly
A popular alternative strategy is to use HTTP cookies to communicate A popular alternative strategy is to use HTTP cookies ([RFC6265]) to
some information about the client. However, this approach is also communicate some information about the client. However, this
not cache friendly, bound by same origin policy, and imposes approach is also not cache friendly, bound by same origin policy, and
additional client-side latency by requiring JavaScript execution to imposes additional client-side latency by requiring JavaScript
create and manage HTTP cookies. execution to create and manage HTTP cookies.
This document defines a set of new request header fields that allow This document defines a set of new request header fields that allow
the client to perform proactive content negotiation [RFC7231] by the client to perform proactive content negotiation (Section 3.4.1 of
indicating a list of device and agent specific preferences, through a [RFC7231]) by indicating a list of device and agent specific
mechanism similar to the Accept header which is used to indicate preferences, through a mechanism similar to the Accept header field
preferred response formats. which is used to indicate preferred response formats.
Client Hints does not supersede or replace the User-Agent header Client Hints does not supersede or replace the User-Agent header
field. Existing device detection mechanisms can continue to use both field. Existing device detection mechanisms can continue to use both
mechanisms if necessary. By advertising its capabilities within a mechanisms if necessary. By advertising its capabilities within a
request header field, Client Hints allows for cache friendly and request header field, Client Hints allows for cache friendly and
proactive content negotiation. proactive content negotiation.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 5 skipping to change at page 4, line 13
parameter rule from [RFC7231]. parameter rule from [RFC7231].
2. Client Hint Request Header Fields 2. Client Hint Request Header Fields
A Client Hint request header field is a HTTP header field that is A Client Hint request header field is a HTTP header field that is
used by HTTP clients to indicate configuration data that can be used used by HTTP clients to indicate configuration data that can be used
by the server to select an appropriate response. Each one conveys a by the server to select an appropriate response. Each one conveys a
list of client preferences that the server can use to adapt and list of client preferences that the server can use to adapt and
optimize the response. optimize the response.
This document defines a selection of Client Hint request header
fields, and can be referenced by other specifications wishing to use
the same syntax and processing model.
2.1. Sending Client Hints 2.1. Sending Client Hints
Clients control which Client Hint headers and their respective header Clients control which Client Hint headers and their respective header
fields are communicated, based on their default settings, user fields are communicated, based on their default settings, user
configuration and/or preferences. The user may be given the choice configuration and/or preferences. The user can be given the choice
to enable, disable, or override specific hints. to enable, disable, or override specific hints.
The client and server, or an intermediate proxy, may use an opt-in The client and server, or an intermediate proxy, can use an opt-in
mechanism to negotiate which fields should be reported to allow for mechanism to negotiate which fields should be reported to allow for
efficient content adaption. efficient content adaption.
2.2. Server Processing of Client Hints 2.2. Server Processing of Client Hints
Servers MAY respond with an optimized response based on one or more Servers respond with an optimized response based on one or more
received hints from the client. When doing so, and if the resource received hints from the client. When doing so, and if the resource
is cacheable, the server MUST also emit a Vary response header field is cacheable, the server MUST also emit a Vary response header field
([RFC7234]), and optionally Key ([I-D.ietf-httpbis-key]), to indicate (Section 7.1.4 of [RFC7231]), and optionally Key
which hints were used and whether the selected response is ([I-D.ietf-httpbis-key]), to indicate which hints were used and
appropriate for a later request. whether the selected response is appropriate for a later request.
Further, depending on the used hint, the server MAY also need to emit Further, depending on the used hint, the server can emit additional
additional response header fields to confirm the property of the response header fields to confirm the property of the response, such
response, such that the client can adjust its processing. For that the client can adjust its processing. For example, this
example, this specification defines "Content-DPR" response header specification defines "Content-DPR" response header field that needs
field that MUST be returned by the server when the "DPR" hint is used to be returned by the server when the "DPR" hint is used to select
to select the response. the response.
2.2.1. Advertising Support for Client Hints 2.2.1. Advertising Support for Client Hints
Servers can advertise support for Client Hints using the Accept-CH Servers can advertise support for Client Hints using the Accept-CH
header or an equivalent HTML meta element with http-equiv attribute. header field or an equivalent HTML meta element with http-equiv
attribute ([W3C.REC-html5-20141028]).
Accept-CH = #token Accept-CH = #token
For example: For example:
Accept-CH: DPR, Width, Viewport-Width, Downlink Accept-CH: DPR, Width, Viewport-Width, Downlink
When a client receives Accept-CH, it SHOULD append the Client Hint When a client receives Accept-CH, it SHOULD append the Client Hint
headers that match the advertised field-values. For example, based header fields that match the advertised field-values. For example,
on Accept-CH example above, the client would append DPR, Width, based on Accept-CH example above, the client would append DPR, Width,
Viewport-Width, and Downlink headers to all subsequent requests. Viewport-Width, and Downlink header fields to all subsequent
requests.
2.2.2. Interaction with Caches 2.2.2. Interaction with Caches
When selecting an optimized response based on one or more Client When selecting an optimized response based on one or more Client
Hints, and if the resource is cacheable, the server MUST also emit a Hints, and if the resource is cacheable, the server needs to emit a
Vary response header field ([RFC7234]) to indicate which hints were Vary response header field ([RFC7234]) to indicate which hints were
used and whether the selected response is appropriate for a later used and whether the selected response is appropriate for a later
request. request.
Vary: DPR Vary: DPR
Above example indicates that the cache key should be based on the DPR Above example indicates that the cache key needs to include the DPR
header. header field.
Vary: DPR, Width, Downlink Vary: DPR, Width, Downlink
Above example indicates that the cache key should be based on the Above example indicates that the cache key needs to include the DPR,
DPR, Width, and Downlink headers. Width, and Downlink header fields.
Client Hints MAY be combined with Key ([I-D.ietf-httpbis-key]) to Client Hints MAY be combined with Key ([I-D.ietf-httpbis-key]) to
enable fine-grained control of the cache key for improved cache enable fine-grained control of the cache key for improved cache
efficiency. For example, the server MAY return the following set of efficiency. For example, the server can return the following set of
instructions: instructions:
Key: DPR;partition=1.5:2.5:4.0 Key: DPR;partition=1.5:2.5:4.0
Above example indicates that the cache key should be based on the Above example indicates that the cache key needs to include the value
value of the DPR header with three segments: less than 1.5, 1.5 to of the DPR header field with three segments: less than 1.5, 1.5 to
less than 2.5, and 4.0 or greater. less than 2.5, and 4.0 or greater.
Key: Width;div=320 Key: Width;div=320
Above example indicates that the cache key should be based on the Above example indicates that the cache key needs to include the value
value of the Width header and be partitioned into groups of 320: of the Width header field and be partitioned into groups of 320:
0-320, 320-640, and so on. 0-320, 320-640, and so on.
Key: Downlink;partition=0.5:1.0:3.0:5.0:10 Key: Downlink;partition=0.5:1.0:3.0:5.0:10
Above example indicates that the cache key should be based on the Above example indicates that the cache key needs to include the
(Mbps) value of the Downlink header with six segments: less than 0.5, (Mbps) value of the Downlink header field with six segments: less
0.5 to less than 1.0, 1.0 to less than 3.0, 3.0 to less than 5.0, 5.0 than 0.5, 0.5 to less than 1.0, 1.0 to less than 3.0, 3.0 to less
to less than 10; 10 or higher. than 5.0, 5.0 to less than 10; 10 or higher.
3. The DPR Client Hint 3. The DPR Client Hint
The "DPR" header field is a number that, in requests, indicates the The "DPR" request header field is a number that indicates the
client's current Device Pixel Ratio (DPR), which is the ratio of client's current Device Pixel Ratio (DPR), which is the ratio of
physical pixels over CSS px of the layout viewport on the device. physical pixels over CSS px (Section 5.2 of
[W3C.CR-css-values-3-20150611]) of the layout viewport (Section 9.1.1
of [CSS2]) on the device.
DPR = 1*DIGIT [ "." 1*DIGIT ] DPR = 1*DIGIT [ "." 1*DIGIT ]
If DPR occurs in a message more than once, the last value overrides If DPR occurs in a message more than once, the last value overrides
all previous occurrences. all previous occurrences.
3.1. Confirming Selected DPR 3.1. Confirming Selected DPR
The "Content-DPR" header field is a number that indicates the ratio The "Content-DPR" response header field is a number that indicates
between physical pixels over CSS px of the selected image response. the ratio between physical pixels over CSS px of the selected image
response.
Content-DPR = 1*DIGIT [ "." 1*DIGIT ] Content-DPR = 1*DIGIT [ "." 1*DIGIT ]
DPR ratio affects the calculation of intrinsic size of image DPR ratio affects the calculation of intrinsic size of image
resources on the client - i.e. typically, the client automatically resources on the client - i.e. typically, the client automatically
scales the natural size of the image by the DPR ratio to derive its scales the natural size of the image by the DPR ratio to derive its
display dimensions. As a result, the server must explicitly indicate display dimensions. As a result, the server MUST explicitly indicate
the DPR of the selected image response whenever the DPR hint is used, the DPR of the selected image response whenever the DPR hint is used,
and the client must use the DPR value returned by the server to and the client MUST use the DPR value returned by the server to
perform its calculations. In case the server returned Content-DPR perform its calculations. In case the server returned Content-DPR
value contradicts previous client-side DPR indication, the server value contradicts previous client-side DPR indication, the server
returned value must take precedence. returned value MUST take precedence.
Note that DPR confirmation is only required for image responses, and Note that DPR confirmation is only required for image responses, and
the server does not need to confirm the resource width as this value the server does not need to confirm the resource width as this value
can be derived from the resource itself once it is decoded by the can be derived from the resource itself once it is decoded by the
client. client.
If Content-DPR occurs in a message more than once, the last value If Content-DPR occurs in a message more than once, the last value
overrides all previous occurrences. overrides all previous occurrences.
4. The Width Client Hint 4. The Width Client Hint
The "Width" header field is a number that, in requests, indicates the The "Width" request header field is a number that indicates the
resource width in physical px (i.e. intrinsic size of an image). The desired resource width in physical px (i.e. intrinsic size of an
provided physical px value is a number rounded to the largest image). The provided physical px value is a number rounded to the
smallest following integer (i.e. ceiling value). largest smallest following integer (i.e. ceiling value).
Width = 1*DIGIT Width = 1*DIGIT
If the resource width is not known at the time of the request or the If the desired resource width is not known at the time of the request
resource does not have a display width, the Width header field may be or the resource does not have a display width, the Width header field
omitted. If Width occurs in a message more than once, the last value can be omitted. If Width occurs in a message more than once, the
overrides all previous occurrences. last value overrides all previous occurrences.
5. The Viewport-Width Client Hint 5. The Viewport-Width Client Hint
The "Viewport-Width" header field is a number that, in requests, The "Viewport-Width" request header field is a number that indicates
indicates the layout viewport width in CSS px. The provided CSS px the layout viewport width in CSS px. The provided CSS px value is a
value is a number rounded to the largest smallest following integer number rounded to the largest smallest following integer (i.e.
(i.e. ceiling value). ceiling value).
Viewport-Width = 1*DIGIT Viewport-Width = 1*DIGIT
If Viewport-Width occurs in a message more than once, the last value If Viewport-Width occurs in a message more than once, the last value
overrides all previous occurrences. overrides all previous occurrences.
6. The Downlink Client Hint 6. The Downlink Client Hint
The "Downlink" header field is a number that, in requests, indicates The "Downlink" request header field is a number that indicates the
the client's maximum downlink speed in megabits per second (Mbps), as client's maximum downlink speed in megabits per second (Mbps), as
defined by the "downlinkMax" attribute in the W3C Network Information defined by the "downlinkMax" attribute in the W3C Network Information
API. API ([NETINFO]).
Downlink = 1*DIGIT [ "." 1*DIGIT ] Downlink = 1*DIGIT [ "." 1*DIGIT ]
If Downlink occurs in a message more than once, the minimum value If Downlink occurs in a message more than once, the minimum value
should be used to override other occurrences. should be used to override other occurrences.
7. The Save-Data Hint 7. The Save-Data Client Hint
The "Save-Data" header field is a token that, in requests, indicates The "Save-Data" request header field is a token that indicates
client's preference for reduced data usage, due to high transfer client's preference for reduced data usage, due to high transfer
costs, slow connection speeds, or other reasons. costs, slow connection speeds, or other reasons.
Save-Data = "on" Save-Data : sd-token *( ";" [sd-token] )
sd-token = token
The token is a signal indicating explicit user opt-in into a reduced This document defines the "on" sd-token value, which is used as a
data usage mode on the client, and when communicated to origins signal indicating explicit user opt-in into a reduced data usage mode
allows them to deliver alternate content honoring such preference - on the client, and when communicated to origins allows them to
e.g. smaller image and video resources, alternate markup, and so on. deliver alternate content honoring such preference - e.g. smaller
image and video resources, alternate markup, and so on. New token
and extension token values can only be defined by revisions of this
specification.
8. Examples 8. Examples
For example, given the following request headers: For example, given the following request header fields:
DPR: 2.0 DPR: 2.0
Width: 320 Width: 320
Viewport-Width: 320 Viewport-Width: 320
The server knows that the device pixel ratio is 2.0, that the The server knows that the device pixel ratio is 2.0, that the
intended display width of requested resource is 160 CSS px (320 intended display width of the requested resource is 160 CSS px (320
physical pixels at 2x resolution), and that the viewport width is 320 physical pixels at 2x resolution), and that the viewport width is 320
CSS px. CSS px.
If the server uses above hints to perform resource selection for an If the server uses above hints to perform resource selection for an
image asset, it must confirm its selection via the Content-DPR image asset, it must confirm its selection via the Content-DPR
response header to allow the client to calculate the appropriate response header to allow the client to calculate the appropriate
intrinsic size of the image response. The server does not need to intrinsic size of the image response. The server does not need to
confirm resource width, only the ratio between physical pixels and confirm resource width, only the ratio between physical pixels and
CSS px of the selected image resource: CSS px of the selected image resource:
Content-DPR: 1.0 Content-DPR: 1.0
The Content-DPR response header indicates to the client that the The Content-DPR response header field indicates to the client that
server has selected resource with DPR ratio of 1.0. The client may the server has selected resource with DPR ratio of 1.0. The client
use this information to perform additional processing on the resource can use this information to perform additional processing on the
- for example, calculate the appropriate intrinsic size of the image resource - for example, calculate the appropriate intrinsic size of
resource such that it is displayed at the correct resolution. the image resource such that it is displayed at the correct
resolution.
Alternatively, the server could select an alternate resource based on Alternatively, the server could select an alternate resource based on
the maximum downlink speed advertised in the request headers: the maximum downlink speed advertised in the request header fields:
Downlink: 0.384 Downlink: 0.384
The server knows that the client's maximum downlink speed is The server knows that the client's maximum downlink speed is
0.384Mbps (GPRS EDGE), and it may use this information to select an 0.384Mbps (GPRS EDGE), and it can use this information to select an
optimized resource - for example, an alternate image asset, optimized resource - for example, an alternate image asset,
stylesheet, HTML document, media stream, and so on. stylesheet, HTML document, media stream, and so on.
9. Security Considerations 9. Security Considerations
Client Hints defined in this specification do not expose any new Client Hints defined in this specification do not expose any new
information about the user's environment beyond what is already information about the user's environment beyond what is already
available to, and may be communicated by, the application at runtime available to, and can be communicated by, the application at runtime
via JavaScript - e.g. viewport and image display width, device pixel via JavaScript - e.g. viewport and image display width, device pixel
ratio, and so on. ratio, and so on.
However, implementors should consider the privacy implications of However, implementors should consider the privacy implications of
various methods to enable delivery of Client Hints - see "Sending various methods to enable delivery of Client Hints - see "Sending
Client Hints" section. For example, sending Client Hints on all Client Hints" section. For example, sending Client Hints on all
requests may make information about the user's environment available requests can make information about the user's environment available
to origins that otherwise did not have access to this data (e.g. to origins that otherwise did not have access to this data (e.g.
origins hosting non-script resources), which may or not be the origins hosting non-script resources), which might or not be the
desired outcome. The implementors may want to provide mechanisms to desired outcome. The implementors can provide mechanisms to control
control such behavior via explicit opt-in, or other mechanisms. such behavior via explicit opt-in, or other mechanisms. Similarly,
Similarly, the implementors should consider how and whether delivery the implementors should consider how and whether delivery of Client
of Client Hints is affected when the user is in "incognito" or Hints is affected when the user is in "incognito" or similar privacy
similar privacy mode. mode.
10. IANA Considerations 10. IANA Considerations
This document defines the "Accept-CH", "DPR", "Width", and "Downlink" This document defines the "Accept-CH", "DPR", "Width", and "Downlink"
HTTP request fields, "Content-DPR" HTTP response field, and registers HTTP request fields, "Content-DPR" HTTP response field, and registers
them in the Permanent Message Header Fields registry. them in the Permanent Message Header Fields registry.
o Header field name: DPR 10.1. Accept-CH
o Header field name: Accept-CH
o Applicable protocol: HTTP o Applicable protocol: HTTP
o Status: standard o Status: standard
o Author/Change controller: IETF o Author/Change controller: IETF
o Specification document(s): [this document] o Specification document(s): Section 2.2.1
o Related information: for Client Hints o Related information: for Client Hints
o Header field name: Width
10.2. Content-DPR
o Header field name: Content-DPR
o Applicable protocol: HTTP o Applicable protocol: HTTP
o Status: standard o Status: standard
o Author/Change controller: IETF o Author/Change controller: IETF
o Specification document(s): [this document] o Specification document(s): Section 3.1 of this document
o Related information: for Client Hints o Related information: for Client Hints
o Header field name: Viewport-Width
10.3. Downlink
o Header field name: Downlink
o Applicable protocol: HTTP o Applicable protocol: HTTP
o Status: standard o Status: standard
o Author/Change controller: IETF o Author/Change controller: IETF
o Specification document(s): [this document] o Specification document(s): Section 6 of this document
o Related information: for Client Hints o Related information: for Client Hints
o Header field name: Downlink
10.4. DPR
o Header field name: DPR
o Applicable protocol: HTTP o Applicable protocol: HTTP
o Status: standard o Status: standard
o Author/Change controller: IETF o Author/Change controller: IETF
o Specification document(s): [this document] o Specification document(s): Section 3 of this document
o Related information: for Client Hints o Related information: for Client Hints
o Header field name: Content-DPR
10.5. Save-Data
o Header field name: Save-Data
o Applicable protocol: HTTP o Applicable protocol: HTTP
o Status: standard o Status: standard
o Author/Change controller: IETF o Author/Change controller: IETF
o Specification document(s): [this document] o Specification document(s): Section 7 of this document
o Related information: for Client Hints o Related information: for Client Hints
o Header field name: Accept-CH
10.6. Viewport-Width
o Header field name: Viewport-Width
o Applicable protocol: HTTP o Applicable protocol: HTTP
o Status: standard o Status: standard
o Author/Change controller: IETF o Author/Change controller: IETF
o Specification document(s): [this document] o Specification document(s): Section 5 of this document
o Related information: for Client Hints o Related information: for Client Hints
o Header field name: Save-Data
10.7. Width
o Header field name: Width
o Applicable protocol: HTTP o Applicable protocol: HTTP
o Status: standard o Status: standard
o Author/Change controller: IETF o Author/Change controller: IETF
o Specification document(s): [this document] o Specification document(s): Section 4 of this document
o Related information: for Client Hints o Related information: for Client Hints
11. Normative References 11. References
11.1. Normative References
[CSS2] Bos, B., Celic, T., Hickson, I., and H. Lie, "Cascading
Style Sheets Level 2 Revision 1 (CSS 2.1) Specification",
W3C Recommendation REC-CSS2-20110607, June 2011,
<http://www.w3.org/TR/2011/REC-CSS2-20110607>.
[I-D.ietf-httpbis-key] [I-D.ietf-httpbis-key]
Fielding, R. and m. mnot, "The Key HTTP Response Header Fielding, R. and M. Nottingham, "The Key HTTP Response
Field", draft-ietf-httpbis-key-00 (work in progress), Header Field", draft-ietf-httpbis-key-01 (work in
October 2015. progress), March 2016.
[NETINFO] Caceres, M., Moreno, F., and I. Grigorik, "Network
Information API", December 2015, <https://w3c.github.io/
netinfo/>.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
skipping to change at page 11, line 5 skipping to change at page 11, line 48
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <http://www.rfc-editor.org/info/rfc7231>.
[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,
<http://www.rfc-editor.org/info/rfc7234>. <http://www.rfc-editor.org/info/rfc7234>.
[W3C.CR-css-values-3-20150611]
Atkins, T. and E. Etemad, "CSS Values and Units Module
Level 3", World Wide Web Consortium CR CR-css-values-
3-20150611, June 2015,
<http://www.w3.org/TR/2015/CR-css-values-3-20150611>.
[W3C.REC-html5-20141028]
Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
Navara, E., O&#039;Connor, E., and S. Pfeiffer, "HTML5",
World Wide Web Consortium Recommendation REC-
html5-20141028, October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028>.
11.2. Informative References
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
Appendix A. Changes
A.1. Since -00
o Issue 168 (make Save-Data extensible) updated ABNF.
o Issue 163 (CH review feedback) editorial feedback from httpwg
list.
o Issue 153 (NetInfo API citation) added normative reference.
A.2. Since -01
None yet.
Author's Address Author's Address
Ilya Grigorik Ilya Grigorik
Google Google
Email: ilya@igvita.com Email: ilya@igvita.com
URI: https://www.igvita.com/ URI: https://www.igvita.com/
 End of changes. 70 change blocks. 
129 lines changed or deleted 214 lines changed or added

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