idnits 2.17.00 (12 Aug 2021) /tmp/idnits54445/draft-nottingham-http-browser-hints-00.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 17, 2011) is 4021 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft May 17, 2011 4 Intended status: Informational 5 Expires: November 18, 2011 7 HTTP Browser Hints 8 draft-nottingham-http-browser-hints-00 10 Abstract 12 Over time, Web browsers have adapted how they use HTTP based upon 13 common server configurations and behaviours. While this is necessary 14 in the common case, it can be detrimental for performance and 15 interoperability. 17 This document establishes a mechanism whereby origin servers can make 18 available hints for browsers about their preferences and 19 capabilities, without imposing overhead on their interactions or 20 requiring support for them. 22 This is intended to allow browsers to safely optimise connections to 23 servers. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 18, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. A file format for Browser Hints . . . . . . . . . . . . . . . . 3 62 4. Discovering Browser Hints for a Web site . . . . . . . . . . . 4 63 5. Pre-defined Browser Hints . . . . . . . . . . . . . . . . . . . 4 64 5.1. max-conns . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5.2. pconn-ip . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5.3. max-pipeline-depth . . . . . . . . . . . . . . . . . . . . 5 67 5.4. small-hdrs . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.5. no-referer . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5.6. send-ref . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. The Ref HTTP Request Header . . . . . . . . . . . . . . . . . . 6 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 8.1. The 'browser-hints' Well-Known URI . . . . . . . . . . . . 6 74 8.2. The HTTP Browser Hints Registry . . . . . . . . . . . . . . 6 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 HTTP [RFC2616] clients -- especially browsers -- typically use 84 hardcoded values or heuristics to determine how many TCP connections 85 to use to a server, based on common-case server behaviours and 86 limitations. 88 Likewise, they often send voluminous request headers (e.g., in User- 89 Agent and Allow) because they fear that changing those headers' 90 values will break some sites that depend upon specific values. 92 These are just two examples of common, conservative behaviour by 93 browsers that is good for interoperability, but potentially bad for 94 performance in certain circumstances. 96 This memo proposes a mechanism whereby a HTTP server can advertise 97 hints for browsers (and other clients), so that communication with 98 them can be optimised. 100 It does so by defining a file format for such Browser Hints 101 Section 3, and defining how clients can discover it for a given Web 102 site Section 4. Finally, an extensible vocabulary of hints is 103 defined Section 5. 105 Feedback for this draft should take place on the 106 apps-discuss@ietf.org mailing list 107 . 109 2. Requirements 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. A file format for Browser Hints 117 Browser hints are indicating using a JSON [RFC4627] formatted file, 118 containing a single object whose member's names are browser hints, as 119 defined by the registry Section 8.2. 121 For example; 123 { 124 "max-conns": 5, 125 "small-hdrs": true 126 } 128 By their nature, all browser hints are optional; i.e., browsers are 129 free to ignore them. 131 4. Discovering Browser Hints for a Web site 133 The hints relevant to a given site can be determined by fetching the 134 URI path "/.well-known/browser-hints" for that site. 136 Typically, clients (especially browsers) will not block other 137 requests to a site while fetching the browser hints (because they're 138 optional); instead, it will usually be done concurrently with other 139 requests, or on idle connections for future use. 141 In this specification, "site" is scoped by the URI scheme and 142 authority. As such, all of the following are considered to be 143 different sites, and therefore have different browser hints: 145 o http://foo.com/ 146 o https://foo.com/ 147 o http://foo.com:8000/ 148 o http://www.foo.com/ 150 Clients SHOULD follow HTTP 3xx redirects when retrieving hints. 152 A successful response is valid for its associated site for as long as 153 it can be cached in HTTP. 155 If the response has a 200 status code but no explicit freshness 156 (e.g., a Cache-Control: max-age or Expires: header), browsers SHOULD 157 cache the response heuristically for a generous fixed period (e.g., 158 30 days). 160 5. Pre-defined Browser Hints 162 5.1. max-conns 164 o Browser Hint Name: max-conns 165 o Description: When present, this hint indicates the maximum number 166 of concurrent persistent connections that the site would like 167 clients to use. 168 o Value Type: number 169 o Contact: mnot@mnot.net 171 5.2. pconn-ip 173 o Browser Hint Name: pconn-ip 174 o Description: When true, this hint indicates that the site allows 175 clients to reuse persistent connections keyed by IP address, 176 rather than by hostname. Note that all sites that are sharing the 177 connection MUST declare this hint for it to be used, and if a 178 transport-layer certificate is in use (e.g., for TLS [RFC5246]), 179 it MUST be valid for all sites. 180 o Value Type: true | false 181 o Contact: mnot@mnot.net 182 o Specification: [this document] 184 In other words, if both www.example.com and foo.example.org resolve 185 to the address 192.0.2.5, and indicate this hint, then clients can 186 send a request to www.example.com and then a request to 187 foo.example.org on the same TCP connection to that address. 189 If any of the sites grouped together for the purposes of pconn-ip 190 declare a max-conns hint, the max-conns value for that address is 191 considered to be the maximum of the declared max-conn hints present. 193 5.3. max-pipeline-depth 195 o Browser Hint Name: max-pipeline-depth 196 o Description: When present, this hint indicates the maximum number 197 of pipelined requests per connection that the site would like 198 clients to use. 199 o Value Type: number 200 o Contact: mnot@mnot.net 202 5.4. small-hdrs 204 o Browser Hint Name: small-hdrs 205 o Description: When true, this hint indicates that clients can omit 206 the Accept and Accept-Charset request headers when communicating 207 with the site, and that they can use a shortened version of the 208 User-Agent header. 209 o Value Type: true | false 210 o Contact: mnot@mnot.net 212 5.5. no-referer 214 o Browser Hint Name: no-referer 215 o Description: When true, this hint indicates that clients can omit 216 the Referer HTTP request header when sending requests to the site. 218 o Value Type: true | false 219 o Contact: mnot@mnot.net 221 5.6. send-ref 223 o Browser Hint Name: send-ref 224 o Description: When true, this hint indicates that clients can omit 225 the Referer HTTP request header when sending requests to the site, 226 if they instead send a Ref HTTP request header (see Section 6). 227 o Value Type: true | false 228 o Contact: mnot@mnot.net 230 6. The Ref HTTP Request Header 232 TBD: relative URI referer header 234 7. Security Considerations 236 TBD 238 8. IANA Considerations 240 8.1. The 'browser-hints' Well-Known URI 242 This document defines the "browser-hints" Well-Known URI [RFC5785]. 244 o URI suffix: browser-hints 245 o Change controller: mnot@mnot.net 246 o Specification document(s): [this document] 247 o Related information: 249 8.2. The HTTP Browser Hints Registry 251 This document establishes the HTTP Browser Hints Registry. 253 New hints are registered First Come First Served (see [RFC5226]), by 254 sending e-mail to (or using other mechanisms, 255 as established by IANA). 257 Registration requests MUST use the following template: 259 o Browser Hint Name: [name of hint] 260 o Description: [description of hint] 261 o Value Type: [JSON value type] 262 o Contact: [e-mail address(es)] 263 o Specification: [optional; reference or URI to more info] 265 New hints MUST be optional; they cannot place requirements upon 266 implementations. 268 Likewise, new hints MUST be relevant to browser use cases; other non- 269 browsing hints and metadata would make the hints response undesirably 270 large. However, note that non-browser clients MAY use them. 272 Finally, new hints MUST NOT make communication non-conformant with 273 HTTP itself; i.e., this is not a mechanism for changing the HTTP 274 protocol in incompatible ways. For example, if a hint indicates that 275 browsers can compress request headers using GZIP, intermediaries that 276 are interposed are likely to fail. 278 The initial contents of the registry are defined in Section 5. 280 9. References 282 9.1. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 288 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 289 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 291 [RFC4627] Crockford, D., "The application/json Media Type for 292 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 294 9.2. Informative References 296 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 297 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 298 May 2008. 300 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 301 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 303 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 304 Uniform Resource Identifiers (URIs)", RFC 5785, 305 April 2010. 307 Appendix A. Acknowledgements 309 Thanks to Mike Belshe, Anirban Kundu, Patrick McManus, and Steve 310 Souders for their suggestions and feedback. 312 The author takes all responsibility for errors and omissions. 314 Author's Address 316 Mark Nottingham 318 Email: mnot@mnot.net 319 URI: http://www.mnot.net/