idnits 2.17.1 draft-grigorik-http-client-hints-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 4, 2014) is 3522 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5226' is defined on line 324, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-fielding-http-key-02 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Grigorik 3 Internet-Draft Google 4 Intended status: Informational September 4, 2014 5 Expires: March 8, 2015 7 HTTP Client Hints 8 draft-grigorik-http-client-hints-02 10 Abstract 12 An increasing diversity of Web-connected devices and software 13 capabilities has created a need to deliver optimized content for each 14 device. 16 This specification defines a set of HTTP request header fields, 17 colloquially known as Client Hints, to address this. They are 18 intended to be used as input to proactive content negotiation; just 19 as the Accept header allows clients to indicate what formats they 20 prefer, Client Hints allow clients to indicate a list of device and 21 agent specific preferences. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 8, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 59 2. Client Hint Request Header Fields . . . . . . . . . . . . . . . 4 60 2.1. Sending Client Hints . . . . . . . . . . . . . . . . . . . 4 61 2.2. Server Processing of Client Hints . . . . . . . . . . . . . 4 62 2.2.1. Advertising Support for Client Hints . . . . . . . . . 4 63 2.2.2. Interaction with Caches . . . . . . . . . . . . . . . . 5 64 3. The DPR Client Hint . . . . . . . . . . . . . . . . . . . . . . 5 65 4. The RW Client Hint . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Confirming Selected DPR . . . . . . . . . . . . . . . . . . 6 67 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 70 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 There are thousands of different devices accessing the web, each with 76 different device capabilities and preference information. These 77 device capabilities include hardware and software characteristics, as 78 well as dynamic user and client preferences. 80 One way to infer some of these capabilities is through User-Agent 81 (UA) detection against an established database of client signatures. 82 However, this technique requires acquiring such a database, 83 integrating it into the serving path, and keeping it up to date. 84 However, even once this infrastructure is deployed, UA sniffing has 85 numerous limitations: 87 o UA detection cannot reliably identify all static variables 88 o UA detection cannot infer any dynamic client preferences 89 o UA detection requires an external device database 90 o UA detection is not cache friendly 92 A popular alternative strategy is to use HTTP cookies to communicate 93 some information about the client. However, this approach is also 94 not cache friendly, bound by same origin policy, and imposes 95 additional client-side latency by requiring JavaScript execution to 96 create and manage HTTP cookies. 98 This document defines a set of new request header fields that allow 99 the client to perform proactive content negotiation [RFC7231] by 100 indicating a list of device and agent specific preferences, through a 101 mechanism similar to the Accept header which is used to indicate 102 preferred response formats. 104 Client Hints does not supersede or replace the User-Agent header 105 field. Existing device detection mechanisms can continue to use both 106 mechanisms if necessary. By advertising its capabilities within a 107 request header field, Client Hints allows for cache friendly and 108 proactive content negotiation. 110 1.1. Notational Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 This document uses the Augmented Backus-Naur Form (ABNF) notation of 117 [RFC5234] with the list rule extension defined in [RFC7230], Appendix 118 B. It includes by reference the DIGIT rule from [RFC5234]; the OWS, 119 field-name and quoted-string rules from [RFC7230]; and the parameter 120 rule from [RFC7231]. 122 2. Client Hint Request Header Fields 124 A Client Hint request header field is a HTTP header field that is 125 used by HTTP clients to indicate configuration data that can be used 126 by the server to select an appropriate response. Each one conveys a 127 list of client preferences that the server can use to adapt and 128 optimize the response. 130 This document defines a selection of Client Hint request header 131 fields, and can be referenced by other specifications wishing to use 132 the same syntax and processing model. 134 2.1. Sending Client Hints 136 Clients control which Client Hint headers and their respective header 137 fields are communicated, based on their default settings, user 138 configuration and/or preferences. The user may be given the choice 139 to enable, disable, or override specific hints. 141 The client and server, or an intermediate proxy, may use an opt-in 142 mechanism to negotiate which fields should be reported to allow for 143 efficient content adaption. 145 2.2. Server Processing of Client Hints 147 Servers can modify the response sent based upon Client Hints. When 148 doing so, it MUST confirm the selection for certain hints and 149 indicate the value of selected resource via corresponding response 150 header. For example, this specification defines "DPR" that 151 corresponds to the "DPR" request header field. 153 2.2.1. Advertising Support for Client Hints 155 Servers can advertise support for Client Hints using the Accept-CH 156 header or an equivalent HTML meta element with http-equiv attribute. 158 Accept-CH = #token 160 For example: 162 Accept-CH: DPR, RW 164 When a client receives Accept-CH, it SHOULD append the Client Hint 165 headers that match the advertised field-values. For example, based 166 on Accept-CH example above, the client would append DPR and RW 167 headers to all subsequent requests. 169 2.2.2. Interaction with Caches 171 Client Hints MAY be combined with Key ([I-D.fielding-http-key]) to 172 enable fine-grained control of the cache key for improved cache 173 efficiency. For example, the server may return the following set of 174 instructions: 176 Key: DPR;r=[1.5:] 178 Above examples indicates that the cache key should be based on the 179 DPR header, and the resource should be cached and made available for 180 any client whose device pixel ratio is 1.5, or higher. 182 Key: RW;r=[320:640] 184 Above example indicates that the cache key should be based on the RW 185 header, and the resource should be cached and made available for any 186 request whose display width falls between 320 and 640px. 188 In absence of support for fine-grained control of the cache key via 189 the Key header field, Vary response header can be used to indicate 190 that served resource has been adapted based on specified Client Hint 191 preferences. 193 Vary: DPR 195 Above example indicates that the cache key should be based on the DPR 196 header. 198 Vary: DPR, RW 200 Above example indicates that the cache key should be based on the DPR 201 and RW headers. 203 3. The DPR Client Hint 205 The "DPR" header field is a number that, in requests, indicates the 206 client's current Device Pixel Ratio (DPR), which is the ratio of 207 physical pixels over CSS px of the layout viewport on the device. 209 DPR = 1*DIGIT [ "." 1*DIGIT ] 211 If DPR occurs in a message more than once, the last value overrides 212 all previous occurrences. 214 4. The RW Client Hint 216 The "RW" header field is a number that, in requests, indicates the 217 Resource Width (RW) in CSS px, which is either the display width of 218 the requested resource (e.g. display width of an image), or the 219 layout viewport width if the resource does not have a display width 220 (e.g. a non-image asset). 222 RW = 1*DIGIT 224 If RW occurs in a message more than once, the last value overrides 225 all previous occurrences. 227 4.1. Confirming Selected DPR 229 The "Content-DPR" header field is a number that indicates the ratio 230 between physical pixels over CSS px of the selected image response. 232 Content-DPR = 1*DIGIT [ "." 1*DIGIT ] 234 DPR ratio affects the calculation of intrinsic size of image 235 resources on the client - i.e. typically, the client automatically 236 scales the natural size of the image by the DPR ratio to derive its 237 display dimensions. As a result, the server must explicitly indicate 238 the DPR of the selected image response whenever the DPR hint is used, 239 and the client must use the DPR value returned by the server to 240 perform its calculations. In case the server returned Content-DPR 241 value contradicts previous client-side DPR indication, the server 242 returned value must take precedence. 244 Note that DPR confirmation is only required for image responses, and 245 the server does not need to confirm the resource width (RW) as this 246 value can be derived from the resource itself once it is decoded by 247 the client. 249 If Content-DPR occurs in a message more than once, the last value 250 overrides all previous occurrences. 252 5. Example 254 For example, given the following request headers: 256 DPR: 2.0 257 RW: 160 259 The server knows that the device pixel ratio is 2.0, and that the 260 intended display width of requested resource is 160 CSS px. 262 If the server uses above hints to perform resource selection for an 263 image asset, it must confirm its selection via the Content-DPR 264 response header to allow the client to calculate the appropriate 265 intrinsic size of the image response. The server does not need to 266 confirm resource width, only the ratio between physical pixels and 267 CSS px of the selected image resource: 269 Content-DPR: 1.0 271 The Content-DPR response header indicates to the client that the 272 server has selected resource with DPR ratio of 1.0. The client may 273 use this information to perform additional processing on the resource 274 - for example, calculate the appropriate intrinsic size of the image 275 resource such that it is displayed at the correct resolution. 277 6. IANA Considerations 279 This document defines the "Accept-CH", "DPR", and "RW" HTTP request 280 fields, "Content-DPR" HTTP response field, and registers them in the 281 Permanent Message Header Fields registry. 283 o Header field name: DPR 284 o Applicable protocol: HTTP 285 o Status: standard 286 o Author/Change controller: Ilya Grigorik, ilya@igvita.com 287 o Specification document(s): [this document] 288 o Related information: for Client Hints 289 o Header field name: RW 290 o Applicable protocol: HTTP 291 o Status: standard 292 o Author/Change controller: Ilya Grigorik, ilya@igvita.com 293 o Specification document(s): [this document] 294 o Related information: for Client Hints 295 o Header field name: Content-DPR 296 o Applicable protocol: HTTP 297 o Status: standard 298 o Author/Change controller: Ilya Grigorik, ilya@igvita.com 299 o Specification document(s): [this document] 300 o Related information: for Client Hints 301 o Header field name: Accept-CH 302 o Applicable protocol: HTTP 303 o Status: standard 304 o Author/Change controller: Ilya Grigorik, ilya@igvita.com 305 o Specification document(s): [this document] 306 o Related information: for Client Hints 308 7. Security Considerations 310 The client controls which header fields are communicated and when. 311 In cases such as incognito or anonymous profile browsing, the header 312 can be omitted if necessary. 314 8. Normative References 316 [I-D.fielding-http-key] 317 Fielding, R. and M. Nottingham, "The Key HTTP Response 318 Header Field", draft-fielding-http-key-02 (work in 319 progress), February 2013. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 325 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 326 May 2008. 328 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 329 Specifications: ABNF", STD 68, RFC 5234, January 2008. 331 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 332 (HTTP/1.1): Message Syntax and Routing", RFC 7230, 333 June 2014. 335 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 336 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 338 Author's Address 340 Ilya Grigorik 341 Google 343 Email: ilya@igvita.com 344 URI: https://www.igvita.com/