draft-ietf-httpbis-client-hints-02.txt   draft-ietf-httpbis-client-hints-03.txt 
HTTP Working Group I. Grigorik HTTP Working Group I. Grigorik
Internet-Draft Google Internet-Draft Google
Intended status: Experimental October 4, 2016 Intended status: Experimental December 2, 2016
Expires: April 7, 2017 Expires: June 5, 2017
HTTP Client Hints HTTP Client Hints
draft-ietf-httpbis-client-hints-02 draft-ietf-httpbis-client-hints-03
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
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 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 April 7, 2017. This Internet-Draft will expire on June 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . . . . . . . 7 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 Client Hint . . . . . . . . . . . . . . . . . . 8 7. The Save-Data Client Hint . . . . . . . . . . . . . . . . . . 8
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10.1. Accept-CH . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Accept-CH . . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Content-DPR . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Content-DPR . . . . . . . . . . . . . . . . . . . . . . 10
10.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 10 10.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 10
10.4. DPR . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.4. DPR . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.5. Save-Data . . . . . . . . . . . . . . . . . . . . . . . 10 10.5. Save-Data . . . . . . . . . . . . . . . . . . . . . . . 11
10.6. Viewport-Width . . . . . . . . . . . . . . . . . . . . . 11 10.6. Viewport-Width . . . . . . . . . . . . . . . . . . . . . 11
10.7. Width . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.7. Width . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 12
A.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 13
A.3. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 13 A.3. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 13
A.4. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
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
skipping to change at page 5, line 8 skipping to change at page 5, line 10
header field or an equivalent HTML meta element with http-equiv header field or an equivalent HTML meta element with http-equiv
attribute ([W3C.REC-html5-20141028]). attribute ([W3C.REC-html5-20141028]).
Accept-CH = #field-name Accept-CH = #field-name
For example: For example:
Accept-CH: DPR, Width, Viewport-Width, Downlink Accept-CH: DPR, Width, Viewport-Width, Downlink
When a client receives Accept-CH, or if it is capable of processing When a client receives Accept-CH, or if it is capable of processing
the HTML response and finds an equivalent HTML meta element, it the HTML response and finds an equivalent HTML meta element, it can
SHOULD append the Client-Hint header fields that match the advertised treat it as a signal that the server is interested in receiving the
field-values to the header list of all subsequent requests. For Client-Hint header fields that match the advertised field-values;
example, based on Accept-CH example above, a user agent could append subsequent requests initiated to the same server and, optionally any
DPR, Width, Viewport-Width, and Downlink header fields to all subresource requests initiated as a result of processing the response
from the server that includes the Accept-CH opt-in, can include the
Client-Hint header fields that match the advertised field-values.
For example, based on Accept-CH example above, a user agent could
append DPR, Width, Viewport-Width, and Downlink header fields to all
subresource requests initiated by the page constructed from the subresource requests initiated by the page constructed from the
response. Alternatively, a client can treat advertised support as a response. Alternatively, a client can treat advertised support as a
persistent origin preference and append same header fields on all persistent origin preference and append same header fields on all
future requests initiated to and by the resources associated with future requests initiated to and by the resources associated with
that origin. that origin.
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 needs to emit a Hints, and if the resource is cacheable, the server needs to emit a
skipping to change at page 6, line 21 skipping to change at page 6, line 29
Above example indicates that the cache key needs to include the Above example indicates that the cache key needs to include the
(Mbps) value of the Downlink header field with six segments: less (Mbps) value of the Downlink header field with six segments: less
than 0.5, 0.5 to less than 1.0, 1.0 to less than 3.0, 3.0 to less than 0.5, 0.5 to less than 1.0, 1.0 to less than 3.0, 3.0 to less
than 5.0, 5.0 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" request header field is a number that 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 (Section 5.2 of physical pixels over CSS px (Section 5.2 of
[W3C.CR-css-values-3-20150611]) of the layout viewport (Section 9.1.1 [W3C.CR-css-values-3-20160929]) of the layout viewport (Section 9.1.1
of [CSS2]) on the device. 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" response header field is a number that indicates The "Content-DPR" response header field is a number that indicates
skipping to change at page 10, line 11 skipping to change at page 10, line 19
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.
10.1. Accept-CH 10.1. Accept-CH
o Header field name: 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): Section 2.2.1 o Specification document(s): Section 2.2.1 of this document
o Related information: for Client Hints o Related information: for Client Hints
10.2. Content-DPR 10.2. Content-DPR
o Header field name: 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): Section 3.1 of this document o Specification document(s): Section 3.1 of this document
o Related information: for Client Hints o Related information: for Client Hints
skipping to change at page 11, line 33 skipping to change at page 11, line 42
11. References 11. References
11.1. Normative References 11.1. Normative References
[CSS2] Bos, B., Celic, T., Hickson, I., and H. Lie, "Cascading [CSS2] Bos, B., Celic, T., Hickson, I., and H. Lie, "Cascading
Style Sheets Level 2 Revision 1 (CSS 2.1) Specification", Style Sheets Level 2 Revision 1 (CSS 2.1) Specification",
W3C Recommendation REC-CSS2-20110607, June 2011, W3C Recommendation REC-CSS2-20110607, June 2011,
<http://www.w3.org/TR/2011/REC-CSS2-20110607>. <http://www.w3.org/TR/2011/REC-CSS2-20110607>.
[NETINFO] Caceres, M., Moreno, F., and I. Grigorik, "Network [NETINFO] Caceres, M., Moreno, F., and I. Grigorik, "Network
Information API", December 2015, <https://w3c.github.io/ Information API", n.d., <https://w3c.github.io/netinfo/>.
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 12, line 15 skipping to change at page 12, line 20
[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] [W3C.CR-css-values-3-20160929]
Atkins, T. and E. Etemad, "CSS Values and Units Module Atkins, T. and E. Etemad, "CSS Values and Units Module
Level 3", World Wide Web Consortium CR CR-css-values- Level 3", World Wide Web Consortium CR CR-css-values-
3-20150611, June 2015, 3-20160929, September 2016, <https://www.w3.org/TR/2016/
<http://www.w3.org/TR/2015/CR-css-values-3-20150611>. CR-css-values-3-20160929>.
[W3C.REC-html5-20141028] [W3C.REC-html5-20141028]
Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
Navara, E., O&#039;Connor, T., and S. Pfeiffer, "HTML5", Navara, E., O&#039;Connor, T., and S. Pfeiffer, "HTML5",
World Wide Web Consortium Recommendation REC- World Wide Web Consortium Recommendation REC-
html5-20141028, October 2014, html5-20141028, October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028>. <http://www.w3.org/TR/2014/REC-html5-20141028>.
11.2. Informative References 11.2. Informative References
skipping to change at page 13, line 4 skipping to change at page 13, line 10
o Issue 168 (make Save-Data extensible) updated ABNF. o Issue 168 (make Save-Data extensible) updated ABNF.
o Issue 163 (CH review feedback) editorial feedback from httpwg o Issue 163 (CH review feedback) editorial feedback from httpwg
list. list.
o Issue 153 (NetInfo API citation) added normative reference. o Issue 153 (NetInfo API citation) added normative reference.
A.2. Since -01 A.2. Since -01
o Issue 200: Moved Key reference to informative. o Issue 200: Moved Key reference to informative.
o Issue 215: Extended passive fingerprinting and mitigation o Issue 215: Extended passive fingerprinting and mitigation
considerations. considerations.
o Changed document status to experimental. o Changed document status to experimental.
A.3. Since -02 A.3. Since -02
o Issue 239: Updated reference to CR-css-values-3
o Issue 240: Updated reference for Network Information API
o Issue 241: Consistency in IANA considerations
o Issue 250: Clarified Accept-CH
A.4. Since -03
None yet. 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. 15 change blocks. 
20 lines changed or deleted 32 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/