idnits 2.17.1 draft-nottingham-http-pipeline-01.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 (March 13, 2011) is 4791 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-12 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-12 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft March 13, 2011 4 Intended status: Informational 5 Expires: September 14, 2011 7 Making HTTP Pipelining Usable on the Open Web 8 draft-nottingham-http-pipeline-01 10 Abstract 12 Pipelining was added to HTTP/1.1 as a means of improving the 13 performance of persistent connections in common cases. While it is 14 deployed in some limited circumstances, it is not widely used by 15 clients on the open Internet. This memo suggests some measures 16 designed to make it more possible for clients to reliably and safely 17 use HTTP pipelining in these situations. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 14, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. HTTP Pipelining Issues . . . . . . . . . . . . . . . . . . . . 4 56 4. Blacklisting Origin Servers . . . . . . . . . . . . . . . . . 4 57 5. Discovering Faulty Proxies . . . . . . . . . . . . . . . . . . 4 58 6. Correlating Responses . . . . . . . . . . . . . . . . . . . . 5 59 7. Hinting Pipelinable Content . . . . . . . . . . . . . . . . . 7 60 8. Indicating Blocking Responses . . . . . . . . . . . . . . . . 7 61 9. Handling Pipelining Problems . . . . . . . . . . . . . . . . . 8 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 12.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 68 Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 9 69 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 HTTP/1.1 [RFC2616] added pipelining -- that is, the ability to have 75 more than one outstanding request on a connection at a particular 76 time -- to improve performance when many requests need to be made 77 (e.g., when an HTML page references several images). 79 Although not usable in all circumstances (POST and other non- 80 idempotent requests cannot be pipelined), for the common case of Web 81 browsing, pipelining seems at first like a broadly useful improvement 82 -- especially since the number of TCP connections browsers and 83 servers can use for a given interaction is limited, and especially 84 where there is noticeable latency present. 86 Indeed, in constrained applications of HTTP such as Subversion, 87 pipelining has been shown to improve end-user perceived latency 88 considerably. 90 However, pipelining is not broadly used on the Web today; while most 91 (but not all) servers and intermediaries support pipelining (to 92 varying degrees), only one major Web browser uses it in its default 93 configuration, and that implementation is reported to use a number of 94 proprietary heuristics to determine when it is safe to pipeline. 96 This memo characterises issues currently encountered in the use of 97 HTTP pipelining, and suggests mechanisms that are designed to make 98 its use more reliable and safe for browsers. 100 Note that this memo does not suggest drastic changes to HTTP, nor 101 does it require that intermediaries change to better support 102 pipelining. Instead, it takes the position that removing the 103 responsibility for making pipelining decisions from browsers, as well 104 as reduce associated risks for browsers, we make it more likely that 105 browsers will support it. 107 This memo should be discussed on the ietf-http-wg@w3.org mailing 108 list, although it is not a work item of the HTTPbis WG. Reviewers 109 are encouraged to pay particular attention to items marked FEEDBACK. 111 2. Requirements 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 3. HTTP Pipelining Issues 119 Anecdotal evidence suggests there are a number of reasons why clients 120 don't use HTTP pipelining by default. Briefly, they are: 121 1. Balking Servers - server implementations can stall pipelined 122 requests, or close their connection when the client attempts to 123 pipeline. This is one of the most commonly cited problems. 124 2. Confused Servers - a few server implementations can respond to 125 pipelined requests in the wrong order. Even fewer might corrupt 126 the actual responses. Because this has security implications 127 (consider multiple users behind such a proxy, or multiple tabs in 128 a browser), this is very concerning. 129 3. Head-of-Line Blocking - Clients don't have enough information 130 about what is useful to pipeline. A given response may take an 131 inordinate amount of time to generate, and/or be large enough to 132 block subsequent responses. Clients who pipeline may face worse 133 performance if they stack requests behind such an expensive 134 request. 136 Note that here, "servers" can also include proxies and other 137 intermediaries, including so-called "transparent" proxies (also known 138 as intercepting proxies). 140 The remainder of this memo proposes mechanisms that can be used to 141 mitigate one or more of these problems; not all of them will survive 142 discussion and implementation. 144 4. Blacklisting Origin Servers 146 To address balking and confused origin servers, a client SHOULD 147 maintain a blacklist of origins that it does not attempt pipelining 148 with. 150 Such a blacklist MAY be populated by external information (e.g., a 151 list of known-bad servers maintained by the browser vendor), and when 152 pipelining has been detected to fail to the origin. 154 5. Discovering Faulty Proxies 156 When a balking or confused server is a proxy, pipelining won't work 157 for any requests sent through it. Therefore, clients SHOULD test the 158 network for such proxies periodically. 160 This can be done by sending pipelined requests to a known server, and 161 examining the responses for errors. 163 For example, if the ExampleBrowser implementation wishes to probe for 164 faulty proxies, it can send a series of requests to 165 "http://browser.example.com/pipeline-test/" and subresources. If the 166 bodies of the resulting responses deviate from those it expects in 167 any way, it is reasonable to assume that a faulty proxy is present, 168 and pipelining SHOULD NOT be used through it. 170 RECOMMENDED measures in such tests include: 172 o Sending a non-trivial number of pipelined requests (e.g., 10) 173 o Sending multiple pipelined requests in the same packet 174 o Inserting request bodies with various sizes 175 o Assuring that caching is disabled, so that requests are end-to-end 176 o Sending a variety of responses types that includes 100 and 304 177 responses 178 o Examining responses to assure that they all appear in the correct 179 order 180 o Examining received requests and responses to assure that they 181 aren't unduly modified 183 These tests SHOULD be performed by clients (both user agent and 184 proxy) upon startup, as well as periodically afterwards to assure 185 that a new intercepting proxy hasn't been interposed. They MAY be 186 performed after a pipelining problem is detected, to determine 187 whether the issue is proxy- related. 189 See for an example 190 implementation. 192 6. Correlating Responses 194 HTTP relies on the context of the connection to associate a given 195 request with its intended response. In HTTP/1.0, this was a 196 reasonable assumption, since only one request could be outstanding at 197 a given time, and each request had exactly one response. 199 HTTP/1.1 made associating requests and responses in a given 200 connection more complex (and therefore fault-prone). Not only does 201 pipelining mean that multiple requests can be outstanding, but also 202 the 1xx series of response status codes introduce the possibility of 203 multiple response messages (syntactically) being associated with a 204 single request. 206 To improve the client's ability to correlate responses with their 207 requests and identify confused origin and proxy servers (as well as 208 serve other potential use cases), this memo introduces the "Assoc- 209 Req" response header field. 211 Assoc-Req = "Assoc-Req" ":" OWS Assoc-Req-v 212 Assoc-Req-v = Method SP absolute-URI 214 The field-value of the Assoc-Req header field is the method and 215 effective request URI of the request associated with the response 216 that it appears in. The URI used MUST be generated using the 217 algorithm for finding the Effective Request URI in 218 [I-D.ietf-httpbis-p1-messaging]. The header field MUST NOT be 219 generated by proxies. 221 For example, given the following request over port 80: 223 GET /foo?it HTTP/1.1 224 Host: www.example.com 226 the appropriate Assoc-Req header field would be: 228 Assoc-Req: GET http://www.example.com/foo?it 230 Note that the Assoc-Req header field is not a perfectly reliable 231 identifier for the request associated with a response; for example, 232 it does not incorporate the selecting headers for content negotiation 233 [I-D.ietf-httpbis-p6-cache], nor does it differentiate request 234 bodies, when present. However, for the purposes of making pipelining 235 more reliable, it is sufficient. 237 A client wishing to use the Assoc-Req response header field to aid in 238 identifying problems in pipelining can compare its values to those of 239 the request that it believes it to be associated with (based upon 240 HTTP's message parsing rules, defined in 241 [I-D.ietf-httpbis-p1-messaging]). If either the method or the URI 242 differ, it indicates that there may be a pipelining-related issue, 243 and the origin server (identified by its (host, port) tuple) SHOULD 244 be blacklisted. 246 A client MAY choose to blacklist any origin server that does not send 247 the Assoc-Req header. 249 FEEDBACK: Omitting the URI scheme and authority (i.e., just making it 250 the path and query components) would make the header easier to 251 generate and avoid some false positives (e.g., when a "reverse proxy" 252 or other URI rewriter is present), but may fail to identify cases 253 where two requests are confused (consider requests for 254 "http://example.com/style.css" and 255 "https://foo.example.net/style.css"). 257 7. Hinting Pipelinable Content 259 It's necessary to assist clients in determining what requests are 260 suitable for pipelining, so that the sole responsibility for deciding 261 what and when to pipeline isn't theirs. This can be done through 262 origin server hinting. 264 Such hints indicates URLs that, when dereferenced, will likely not 265 incur significant latency on the server in generating the response, 266 nor significant latency on the network in transferring the response. 268 What is "significant" is determined by the server. Clients will use 269 these hints to determine what request(s) it is safe to pipeline 270 something else after. 272 For example, if "http://example.com/a" is hinted, a client can be 273 more confident pipelining another request (e.g., to 274 "http://example.com/b") on the same connection afterwards. 276 There are several possible ways that content could be hinted, 277 including: 278 o The "quick" link relation type can appear on individual HTML 279 elements such as "img", "script" and "link" to indicate that the 280 link they contain has low overhead. 281 o A similar link relation could also be used in the HTTP link header 282 to indicate "quick" links within the response in a format-neutral 283 way. 284 o A server can indicate that all its resources are suitable for 285 pipelining by returning a successful response status code (2xx) to 286 requests for the path "/.well-known/pipeline". In the future, a 287 format available at this location could give more fine-grained 288 information. 290 FEEDBACK: thoughts on the suitability of these hinting mechanisms is 291 encouraged, so that the list can eventually be narrowed down. 293 A user agent MAY have a policy of only pipelining to hinted 294 resources. 296 8. Indicating Blocking Responses 298 An alternate way to avoid head-of-line blocking is for the origin 299 server to aggressively indicate when a request would block. 301 This can be done by using a new HTTP status code, 430 WOULD BLOCK. 303 The meaning of "would block" is defined by the server; e.g., it may 304 return this code when the response is known to be over a certain 305 size, or when the code to generate the response is known to take a 306 long time to execute. 308 When a client (user agent or intermediary) receives a 430 WOULD 309 BLOCK, it SHOULD resubmit the associated request on a new or idle 310 connection. 312 An origin server MUST NOT send a 430 WOULD BLOCK status code to 313 clients that do not include a "PWB: 1" (mnemonic: Pipelining Would 314 Block) request header. User Agents that support the status code 315 SHOULD send this header, and intermediaries that are willing to 316 handle its processing MAY append it to requests that do not already 317 include it. 319 A cache MUST NOT store a 430 WOULD BLOCK response, and origin servers 320 SHOULD mark them as explicitly uncacheable (e.g., with Cache-Control: 321 no-store). 323 FEEDBACK: This is a relatively new idea; thoughts? In some ways it's 324 easier to deploy, but it does add a certain amount of latency to 325 requests that block. Theoretically, a Location header could be added 326 to redirect the client to a place where the generated response will 327 be waiting (if the blocking is caused by server-side think time), but 328 this may be impractical to implement. 330 9. Handling Pipelining Problems 332 Upon encountering an indication of pipelining problems with a 333 particular response (e.g., an incorrect Assoc-Req field-value, a 334 pipelined response that stalls), user agents SHOULD discard the 335 response in question, all subsequent responses on the same 336 connection, and close the connection. Unsatisfied requests can be 337 resubmitted, without pipelining, and the implementation can choose 338 not to use pipelining to the same server in the future (see 339 "Blacklisting Origin Servers"). 341 10. Security Considerations 343 TBD 345 11. IANA Considerations 347 TBD 349 12. References 351 12.1. Normative References 353 [I-D.ietf-httpbis-p1-messaging] 354 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 355 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 356 "HTTP/1.1, part 1: URIs, Connections, and Message 357 Parsing", draft-ietf-httpbis-p1-messaging-12 (work in 358 progress), October 2010. 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 12.2. Informative References 365 [I-D.ietf-httpbis-p6-cache] 366 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 367 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 368 "HTTP/1.1, part 6: Caching", 369 draft-ietf-httpbis-p6-cache-12 (work in progress), 370 October 2010. 372 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 373 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 374 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 376 Appendix A. Acknowledgements 378 Thanks to Ilya Grigorik, Anirban Kundu, Patrick McManus and Julian 379 Reschke. The author takes all responsibility for errors and 380 omissions. 382 Appendix B. Frequently Asked Questions 384 Isn't full multiplexing better? 386 While "full" multiplexing is theoretically better, pipelining -- once 387 usable -- is adequate for almost all common Web browsing cases. 388 Since the browser needs to download HTML first, it has an opportunity 389 to receive hints about subsequent requests and pipeline them 390 appropriately. Likewise, by far the most common case for 391 multiplexing on the Web is when a large number of images and other 392 page assets need to be fetched with GET; a perfect use of pipelining, 393 provided that the client has enough information to avoid head-of-line 394 blocking. 396 Why not have the client generate a unique request identifier? 398 While in some ways this would be easier than the approach that the 399 Assoc-Req header takes, it would be more difficult to deploy, because 400 existing caching proxies wouldn't be able to serve the correct 401 identifier when using a cached response. 403 Appendix C. Changes 405 draft -00 to draft -01: 407 o Add guidelines for blacklisting 408 o Remove advice on signature checking (for now) 409 o Clarified problem statement 410 o Rearranged 411 o Added 430 WOULD BLOCK 413 Author's Address 415 Mark Nottingham 417 Email: mnot@mnot.net 418 URI: http://www.mnot.net/