idnits 2.17.1 draft-nottingham-http-browser-hints-05.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 (February 12, 2013) is 4081 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-21 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft February 12, 2013 4 Intended status: Informational 5 Expires: August 16, 2013 7 HTTP Origin and Hop Hints 8 draft-nottingham-http-browser-hints-05 10 Abstract 12 Over time, HTTP clients -- especially Web browsers -- have adapted 13 how they use the protocol based upon common server configurations and 14 behaviours. While this is necessary in the common case, it can be 15 detrimental for performance and interoperability. 17 This document establishes a mechanism whereby both origin servers and 18 intermediaries can make hints available to clients about their 19 preferences and capabilities, without imposing undue overhead on 20 their interactions or requiring support for them. 22 This is intended to allow clients to safely optimise connections to 23 servers. 25 Note to Readers 27 Feedback for this draft should take place on the 28 apps-discuss@ietf.org mailing list 29 . 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 16, 2013. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 66 3. Origin Hints . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Hop Hints . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. Hint Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 6. Pre-defined Hints . . . . . . . . . . . . . . . . . . . . . . 6 70 6.1. Small Request Headers . . . . . . . . . . . . . . . . . . 6 71 6.2. Relative Referers . . . . . . . . . . . . . . . . . . . . 6 72 6.3. Omitting Cookies . . . . . . . . . . . . . . . . . . . . . 6 73 6.4. Sharing Connections . . . . . . . . . . . . . . . . . . . 7 74 6.5. Pipeline Depth . . . . . . . . . . . . . . . . . . . . . . 7 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. The OH HTTP Response Header Field . . . . . . . . . . . . 8 78 8.2. The HH HTTP Response Header Field . . . . . . . . . . . . 8 79 8.3. The HTTP Hints Registry . . . . . . . . . . . . . . . . . 8 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 84 Appendix B. Open Issue: Hint Syntax . . . . . . . . . . . . . . . 10 85 Appendix C. Open Issue: Hint Value Types . . . . . . . . . . . . 10 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 1. Introduction 90 HTTP [HTTP-p1] clients -- especially browsers -- typically use 91 hardcoded values or heuristics to determine how they use TCP, based 92 on common-case server behaviours and limitations. 94 For example, they often send voluminous request headers (e.g., in 95 User-Agent and Allow) because they fear that changing those headers' 96 values will break some sites that depend upon specific values. 98 These conservative behaviours are good for interoperability, but 99 potentially bad for performance in certain circumstances. 101 This document specifies a mechanism whereby a HTTP server can 102 advertise hints for browsers and other clients, so that communication 103 with them can be optimised. 105 It does so by defining two headers; "OH" (Origin Hints) for end-to- 106 end hints from the Origin Server, and "HH" (Hop Hints) for hop-by-hop 107 hints from the upstream server (origin or proxy). A selection of 108 hints are also defined in this document, and a registry is defined to 109 allow future such hints. 111 2. Notational Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 This document uses the Augmented Backus-Naur Form (ABNF) notation of 118 [RFC5234], and explicitly includes the following rules from it: 119 ALPHA, DIGIT. Additionally, it uses the list rule extension defined 120 in [HTTP-p1], Appendix B. 122 3. Origin Hints 124 Origin Hints are applicable to all future requests to the origin 125 [RFC6454] associated with the response, until they are overridden. 126 They are carried in the "OH" header field's value. 128 OH = #hint 130 A hint is considered overridden when an OH header field is seen from 131 the same origin that does not contain the hint, or contains a 132 different value for the hint. 134 Practically speaking, this means that clients MAY cache origin hint 135 values indefinitely, updating them when new OH header fields are seen 136 from an origin. 138 For example, an origin may send an OH header on every response, in 139 which case the latest one seen would be the value used, or it could 140 send one sporadically (e.g., upon connection), in which case the 141 origin hints in effect would be the last one seen by the client. 143 Practically speaking, origins that wish to have their hints available 144 to clients as soon as possible will send them on every response; 145 those that wish to limit the sizes of responses might use some other 146 strategy, knowing that clients will eventually cache their hints. 148 For example: 150 HTTP/1.1 200 OK 151 Content-Type: text/html 152 OH: a,b=6,c 153 Content-Length: 1234 154 Cache-Control: max-age=60 156 ... 158 Here, the origin hints "a", "b", and "c" are indicated; the "b" hint 159 has a value of "6". If a subsequent message from the same origin to 160 the same client were: 162 HTTP/1.1 303 See Other 163 Content-Type: text/html 164 OH: a,b=2 165 Content-Length: 1234 166 Cache-Control: max-age=60 168 ... 170 The client would now consider "a" to still be true, whereas the value 171 of "b" would be 2, and "c" would be false. 173 Origin hints SHOULD NOT be generated by proxy servers. 175 4. Hop Hints 177 Hop Hints are applicable to all future requests on the TCP connection 178 they occur upon, until they are overridden. The are carried in the 179 "HH" header field's value. 181 HH = #hint 183 A hint is considered overridden when an HH header field is seen on 184 the same connection that does not contain the hint, or contains a 185 different value for the hint. 187 Typically, a server (whether origin or proxy) will send the HH header 188 field on the first response, omitting it from subsequent responses 189 unless it wishes to change a value. 191 When it occurs in a message, the HH header field MUST be listed in 192 the Connection header's field-value. 194 For example: 196 HTTP/1.1 404 Not Found 197 Content-Type: text/plain 198 HH: x,ya 199 Content-Length: 5678 200 Connection: HH 201 Cache-Control: max-age=60 203 ... 205 Here, the hop hints "x" and "ya" are indicated. 207 5. Hint Syntax 209 Both origin hints and hop hints share a common syntax, consisting of 210 a string of alphanumeric characters. This form is designed to be 211 compact without sacrificing readability. 213 Every hint has a case-sensitive hint identifier. 215 hint = 1*ALPHA [ "=" 1*DIGIT ] 217 Hints are allowed to have a numeric argument. However, wherever 218 possible, they are encouraged to be defined as flags (i.e., as a hint 219 identifier only), so that the hints don't consume too much space in 220 responses. 222 Hints can be defined as one of two types: 223 o Boolean - indicated by the presence of the hint identifier. If 224 the hint identifier is absent in the last message containing the 225 relevant hint header field, it is considered false. 227 o Numeric - value indicated by the digits after "=", up to the first 228 non-digit character. 230 Note that HTTP/1.1 allows headers with comma-separated values to be 231 conveyed using multiple instances of the same header; as a result, 232 the hints of a given type (origin or hop) are collected from all 233 instances of that header on the message in question before being 234 considered complete. 236 6. Pre-defined Hints 238 6.1. Small Request Headers 240 o Hint Name: s 241 o Hint Type: origin 242 o Description: When true, this hint indicates that clients can omit 243 the Accept and Accept-Charset request headers when communicating 244 with the origin, and that they can use a shortened version of the 245 User-Agent header. 246 o Value Type: boolean 247 o Contact: mnot@mnot.net 249 This hint can help reduce request sizes. 251 6.2. Relative Referers 253 o Hint Name: r 254 o Hint Type: origin 255 o Description: When true, this hint indicates that the origin 256 prefers a relative URI in the Referer request header. 257 o Value Type: boolean 258 o Contact: mnot@mnot.net 260 This hint can help reduce request sizes. 262 6.3. Omitting Cookies 264 o Hint Name: c 265 o Hint Type: origin 266 o Description: When true, this hint indicates that all cookies 267 [RFC6265] can be omitted in requests to the origin. 268 o Value Type: boolean 269 o Contact: mnot@mnot.net 271 This hint can help reduce request sizes. 273 6.4. Sharing Connections 275 o Hint Name: sc 276 o Hint Type: hop 277 o Description: When true, this hint indicates that the server allows 278 clients to reuse persistent connections keyed by IP address, 279 rather than by hostname. Note that all origins that are sharing 280 the connection MUST declare this hint for it to be used, and if a 281 transport-layer certificate is in use (e.g., for TLS [RFC5246]), 282 it MUST be valid for all origins. 283 o Value Type: boolean 284 o Contact: mnot@mnot.net 285 o Specification: [this document] 286 o Notes: Although it is a Hop Hint, this MUST NOT be set by servers 287 other than origins. 289 In other words, if both www.example.com and foo.example.org resolve 290 to the address 192.0.2.5, and indicate this hint, then clients can 291 send a request to www.example.com and then a request to 292 foo.example.org on the same TCP connection to that address. 294 6.5. Pipeline Depth 296 o Hint Name: p 297 o Hint Type: hop 298 o Description: When present, this hint indicates the maximum number 299 of pipelined requests per connection that the server would like 300 clients to use. 301 o Value Type: numeric 302 o Contact: mnot@mnot.net 304 7. Security Considerations 306 By their nature, hints are both optional and advisory; clients ought 307 to exercise judgement when applying them, as an attacker might use a 308 naive implementation to trick the client into generating abnormal 309 traffic. For example, the "p" hint should not be the only input into 310 determining how deep to pipeline requests. 312 Hints are also only as secure as the channel they are transmitted 313 upon; if HTTP is used in the clear, then hints might be observed 314 (which typically is not a great risk), and modified (which could be, 315 for a naive client implementation). 317 The Hop Hints mechanism uses the "Connection" header to scope the 318 hint to a single HTTP hop. A few old implementations have been 319 observed to not properly strip headers indicated by "Connection". 321 8. IANA Considerations 323 8.1. The OH HTTP Response Header Field 325 This document defines the "OH" HTTP header field, and registers it in 326 the Permanent Message Headers registry. 328 o Header field name: OH 329 o Applicable protocol: HTTP 330 o Status: Informational 331 o Author/Change controller: Mark Nottingham, mnot@mnot.net 332 o Specification document(s): [this document] 333 o Related information: for Origin Hints 335 8.2. The HH HTTP Response Header Field 337 This document defines the "HH" HTTP header field, and registers it in 338 the Permanent Message Headers registry. 340 o Header field name: HH 341 o Applicable protocol: HTTP 342 o Status: Informational 343 o Author/Change controller: Mark Nottingham, mnot@mnot.net 344 o Specification document(s): [this document] 345 o Related information: for Hop Hints 347 8.3. The HTTP Hints Registry 349 This document establishes the HTTP Hints Registry. 351 New hints are registered using Expert Review (see [RFC5226]), by 352 sending e-mail to (or using other mechanisms, 353 as established by IANA). 355 New hints are expected to be implemented in at least one client in 356 common use. The Expert MAY use their judgement in determining what 357 "common" is, and when something is considered to be implemented. 359 New hints MUST be optional; they cannot place requirements upon 360 implementations. 362 Specifically, new hints MUST NOT make communication non-conformant 363 with HTTP itself; i.e., this is not a mechanism for changing the HTTP 364 protocol in incompatible ways. For example, if a hint indicates that 365 browsers can compress request headers using GZIP, intermediaries that 366 are interposed are likely to fail. 368 Registration requests MUST use the following template: 370 o Hint Name: [name of hint] 371 o Hint Type: ["origin" or "hop"] 372 o Description: [description of hint] 373 o Value Type: ["boolean" or "numeric"] 374 o Contact: [e-mail address(es)] 375 o Specification: [optional; reference or URI to more info] 376 o Notes: [optional] 378 The initial contents of the registry are defined in Section 6. 380 9. References 382 9.1. Normative References 384 [HTTP-p1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 385 Protocol (HTTP/1.1): Message Syntax and Routing", 386 draft-ietf-httpbis-p1-messaging-21; (work in progress), 387 Feb 2013. 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 393 Specifications: ABNF", STD 68, RFC 5234, January 2008. 395 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 396 December 2011. 398 9.2. Informative References 400 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 401 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 402 May 2008. 404 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 405 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 407 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 408 April 2011. 410 Appendix A. Acknowledgements 412 Thanks to Mike Belshe, Artur Bergman, William Chan, Jason Duell, 413 Poul-Henning Kamp, Anirban Kundu, Patrick McManus, Ryan Sleevi, Steve 414 Souders, and Martin Thompson for their suggestions and feedback. 416 The author takes all responsibility for errors and omissions. 418 Appendix B. Open Issue: Hint Syntax 420 This revision defines the syntax of hints as a comma-delimited list. 421 This is convenient (especially for delimiting hints with values), but 422 if many hints need to be conveyed, it'll be inefficient. 424 An alternate syntax could remove the commas, but we'd likely be 425 constrained in the number of hints we'd be able to define. 427 Yet another approach would be to define a bitfield, and an ASCII 428 representation of that field. However, this would be cumbersome. 430 Feedback appreciated. 432 Appendix C. Open Issue: Hint Value Types 434 Are the defined hint value types sufficient? Feedback appreciated. 436 Author's Address 438 Mark Nottingham 440 Email: mnot@mnot.net 441 URI: http://www.mnot.net/