Skip to content
This repository
Browse code

-01

  • Loading branch information...
commit 7e47fdcea497f765971ce824c0aaaae29d19b49a 1 parent 317b2c0
Mark Nottingham authored June 25, 2011
21  http-pipeline/README.rst
Source Rendered
... ...
@@ -0,0 +1,21 @@
  1
+
  2
+This is the source for draft-nottingham-http-pipeline, an IETF Internet-Draft.
  3
+
  4
+Requirements
  5
+============
  6
+
  7
+Building requires:
  8
+
  9
+ * xml2rfc - create an 'xml2rfc' directory (or symlink it); see <http://xml.resource.org/>, and
  10
+ * rfc2629xslt - create a 'rfc2629' directory (or symlink); see <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>.
  11
+
  12
+Make Targets
  13
+============
  14
+
  15
+The current version that the build will operate upon is set by the VERSION variable in the makefile.
  16
+
  17
+ * all - build the current version of the textual and HTML drafts.
  18
+ * clean - remove the current version of the textual and HTML drafts.
  19
+ * idnits - check the current version with the idnits tool.
  20
+ * next - create the source XML file for the next version; perform BEFORE 
  21
+   incrementing VERSION.
301  http-pipeline/draft-nottingham-http-pipeline-01.html
... ...
@@ -0,0 +1,301 @@
  1
+<!DOCTYPE html
  2
+  PUBLIC "-//W3C//DTD HTML 4.01//EN">
  3
+<html lang="en"><head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>Making HTTP Pipelining Usable on the Open Web</title><style type="text/css" title="Xml2Rfc (sans serif)">
  4
+a {
  5
+  text-decoration: none;
  6
+}
  7
+a.smpl {
  8
+  color: black;
  9
+}
  10
+a:hover {
  11
+  text-decoration: underline;
  12
+}
  13
+a:active {
  14
+  text-decoration: underline;
  15
+}
  16
+address {
  17
+  margin-top: 1em;
  18
+  margin-left: 2em;
  19
+  font-style: normal;
  20
+}
  21
+body {
  22
+  color: black;
  23
+  font-family: verdana, helvetica, arial, sans-serif;
  24
+  font-size: 10pt;
  25
+}
  26
+cite {
  27
+  font-style: normal;
  28
+}
  29
+dd {
  30
+  margin-right: 2em;
  31
+}
  32
+dl {
  33
+  margin-left: 2em;
  34
+}
  35
+
  36
+dl.empty dd {
  37
+  margin-top: .5em;
  38
+}
  39
+dl p {
  40
+  margin-left: 0em;
  41
+}
  42
+dt {
  43
+  margin-top: .5em;
  44
+}
  45
+h1 {
  46
+  font-size: 14pt;
  47
+  line-height: 21pt;
  48
+  page-break-after: avoid;
  49
+}
  50
+h1.np {
  51
+  page-break-before: always;
  52
+}
  53
+h1 a {
  54
+  color: #333333;
  55
+}
  56
+h2 {
  57
+  font-size: 12pt;
  58
+  line-height: 15pt;
  59
+  page-break-after: avoid;
  60
+}
  61
+h3, h4, h5, h6 {
  62
+  font-size: 10pt;
  63
+  page-break-after: avoid;
  64
+}
  65
+h2 a, h3 a, h4 a, h5 a, h6 a {
  66
+  color: black;
  67
+}
  68
+img {
  69
+  margin-left: 3em;
  70
+}
  71
+li {
  72
+  margin-left: 2em;
  73
+  margin-right: 2em;
  74
+}
  75
+ol {
  76
+  margin-left: 2em;
  77
+  margin-right: 2em;
  78
+}
  79
+ol p {
  80
+  margin-left: 0em;
  81
+}
  82
+p {
  83
+  margin-left: 2em;
  84
+  margin-right: 2em;
  85
+}
  86
+pre {
  87
+  margin-left: 3em;
  88
+  background-color: lightyellow;
  89
+  padding: .25em;
  90
+}
  91
+pre.text2 {
  92
+  border-style: dotted;
  93
+  border-width: 1px;
  94
+  background-color: #f0f0f0;
  95
+  width: 69em;
  96
+}
  97
+pre.inline {
  98
+  background-color: white;
  99
+  padding: 0em;
  100
+}
  101
+pre.text {
  102
+  border-style: dotted;
  103
+  border-width: 1px;
  104
+  background-color: #f8f8f8;
  105
+  width: 69em;
  106
+}
  107
+pre.drawing {
  108
+  border-style: solid;
  109
+  border-width: 1px;
  110
+  background-color: #f8f8f8;
  111
+  padding: 2em;
  112
+}
  113
+table {
  114
+  margin-left: 2em;
  115
+}
  116
+table.header {
  117
+  width: 95%;
  118
+  font-size: 10pt;
  119
+  color: white;
  120
+}
  121
+td.top {
  122
+  vertical-align: top;
  123
+}
  124
+td.topnowrap {
  125
+  vertical-align: top;
  126
+  white-space: nowrap; 
  127
+}
  128
+td.header {
  129
+  background-color: gray;
  130
+  width: 50%;
  131
+}
  132
+td.header a {
  133
+  color: white;
  134
+}
  135
+td.reference {
  136
+  vertical-align: top;
  137
+  white-space: nowrap;
  138
+  padding-right: 1em;
  139
+}
  140
+thead {
  141
+  display:table-header-group;
  142
+}
  143
+ul.toc {
  144
+  list-style: none;
  145
+  margin-left: 1.5em;
  146
+  margin-right: 0em;
  147
+  padding-left: 0em;
  148
+}
  149
+li.tocline0 {
  150
+  line-height: 150%;
  151
+  font-weight: bold;
  152
+  font-size: 10pt;
  153
+  margin-left: 0em;
  154
+  margin-right: 0em;
  155
+}
  156
+li.tocline1 {
  157
+  line-height: normal;
  158
+  font-weight: normal;
  159
+  font-size: 9pt;
  160
+  margin-left: 0em;
  161
+  margin-right: 0em;
  162
+}
  163
+li.tocline2 {
  164
+  font-size: 0pt;
  165
+}
  166
+ul p {
  167
+  margin-left: 0em;
  168
+}
  169
+
  170
+.comment {
  171
+  background-color: yellow;
  172
+}
  173
+.center {
  174
+  text-align: center;
  175
+}
  176
+.error {
  177
+  color: red;
  178
+  font-style: italic;
  179
+  font-weight: bold;
  180
+}
  181
+.figure {
  182
+  font-weight: bold;
  183
+  text-align: center;
  184
+  font-size: 9pt;
  185
+}
  186
+.filename {
  187
+  color: #333333;
  188
+  font-weight: bold;
  189
+  font-size: 12pt;
  190
+  line-height: 21pt;
  191
+  text-align: center;
  192
+}
  193
+.fn {
  194
+  font-weight: bold;
  195
+}
  196
+.hidden {
  197
+  display: none;
  198
+}
  199
+.left {
  200
+  text-align: left;
  201
+}
  202
+.right {
  203
+  text-align: right;
  204
+}
  205
+.title {
  206
+  color: #990000;
  207
+  font-size: 18pt;
  208
+  line-height: 18pt;
  209
+  font-weight: bold;
  210
+  text-align: center;
  211
+  margin-top: 36pt;
  212
+}
  213
+.vcardline {
  214
+  display: block;
  215
+}
  216
+.warning {
  217
+  font-size: 14pt;
  218
+  background-color: yellow;
  219
+}
  220
+
  221
+
  222
+@media print {
  223
+  .noprint {
  224
+    display: none;
  225
+  }
  226
+  
  227
+  a {
  228
+    color: black;
  229
+    text-decoration: none;
  230
+  }
  231
+
  232
+  table.header {
  233
+    width: 90%;
  234
+  }
  235
+
  236
+  td.header {
  237
+    width: 50%;
  238
+    color: black;
  239
+    background-color: white;
  240
+    vertical-align: top;
  241
+    font-size: 12pt;
  242
+  }
  243
+
  244
+  ul.toc a::after {
  245
+    content: leader('.') target-counter(attr(href), page);
  246
+  }
  247
+  
  248
+  a.iref {
  249
+    content: target-counter(attr(href), page);
  250
+  }
  251
+  
  252
+  .print2col {
  253
+    column-count: 2;
  254
+    -moz-column-count: 2;
  255
+    column-fill: auto;
  256
+  }
  257
+}
  258
+
  259
+@page {
  260
+  @top-left {
  261
+       content: "INTERNET DRAFT"; 
  262
+  } 
  263
+  @top-right {
  264
+       content: "March 2011"; 
  265
+  } 
  266
+  @top-center {
  267
+       content: "HTTP Pipelining Enhancements"; 
  268
+  } 
  269
+  @bottom-left {
  270
+       content: "Nottingham"; 
  271
+  } 
  272
+  @bottom-center {
  273
+       content: "Informational"; 
  274
+  } 
  275
+  @bottom-right {
  276
+       content: "[Page " counter(page) "]"; 
  277
+  } 
  278
+}
  279
+
  280
+@page:first { 
  281
+    @top-left {
  282
+      content: normal;
  283
+    }
  284
+    @top-right {
  285
+      content: normal;
  286
+    }
  287
+    @top-center {
  288
+      content: normal;
  289
+    }
  290
+}
  291
+</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyright"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Requirements" href="#rfc.section.2"><link rel="Chapter" title="3 HTTP Pipelining Issues" href="#rfc.section.3"><link rel="Chapter" title="4 Blacklisting Origin Servers" href="#rfc.section.4"><link rel="Chapter" title="5 Discovering Faulty Proxies" href="#rfc.section.5"><link rel="Chapter" title="6 Correlating Responses" href="#rfc.section.6"><link rel="Chapter" title="7 Hinting Pipelinable Content" href="#rfc.section.7"><link rel="Chapter" title="8 Indicating Blocking Responses" href="#rfc.section.8"><link rel="Chapter" title="9 Handling Pipelining Problems" href="#rfc.section.9"><link rel="Chapter" title="10 Security Considerations" href="#rfc.section.10"><link rel="Chapter" title="11 IANA Considerations" href="#rfc.section.11"><link rel="Chapter" href="#rfc.section.12" title="12 References"><link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A"><link rel="Appendix" title="B Frequently Asked Questions" href="#rfc.section.B"><link rel="Appendix" title="C Changes" href="#rfc.section.C"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.478, 2009-10-16 14:30:15, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"><link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"><meta name="DC.Creator" content="Nottingham, M."><meta name="DC.Identifier" content="urn:ietf:id:draft-nottingham-http-pipeline-01"><meta name="DC.Date.Issued" scheme="ISO8601" content="2011-03-13"><meta name="DC.Description.Abstract" content="Pipelining was added to HTTP/1.1 as a means of improving the performance of persistent connections in common cases. While it is deployed in some limited circumstances, it is not widely used by clients on the open Internet. This memo suggests some measures designed to make it more possible for clients to reliably and safely use HTTP pipelining in these situations."><meta name="description" content="Pipelining was added to HTTP/1.1 as a means of improving the performance of persistent connections in common cases. While it is deployed in some limited circumstances, it is not widely used by clients on the open Internet. This memo suggests some measures designed to make it more possible for clients to reliably and safely use HTTP pipelining in these situations."></head><body><table class="header" border="0" cellpadding="1" cellspacing="1"><tr><td class="header left">Network Working Group</td><td class="header right">M. Nottingham</td></tr><tr><td class="header left">Internet Draft</td><td class="header right">March 13, 2011</td></tr><tr><td class="header left">
  292
+        &lt;draft-nottingham-http-pipeline-01&gt;
  293
+      </td><td class="header right"></td></tr><tr><td class="header left">Intended status: Informational</td><td class="header right"></td></tr><tr><td class="header left">Expires: September 14, 2011</td><td class="header right"></td></tr></table><p class="title">Making HTTP Pipelining Usable on the Open Web<br><span class="filename">draft-nottingham-http-pipeline-01</span></p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>Pipelining was added to HTTP/1.1 as a means of improving the performance of persistent connections in common cases. While it is deployed in some limited circumstances, it is not widely used by clients on the open Internet. This memo suggests some measures designed to make it more possible for clients to reliably and safely use HTTP pipelining in these situations.</p><h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1><p>This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.</p><p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.</p><p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as &#8220;work in progress&#8221;.</p><p>The list of current Internet-Drafts can be accessed at &lt;<a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>&gt;.</p><p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.</p><p>This Internet-Draft will expire in September 14, 2011.</p><h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.</p><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li class="tocline0">1.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Introduction</a></li><li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">Requirements</a></li><li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3">HTTP Pipelining Issues</a></li><li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4">Blacklisting Origin Servers</a></li><li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5">Discovering Faulty Proxies</a></li><li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6">Correlating Responses</a></li><li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7">Hinting Pipelinable Content</a></li><li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8">Indicating Blocking Responses</a></li><li class="tocline0">9.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9">Handling Pipelining Problems</a></li><li class="tocline0">10.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.10">Security Considerations</a></li><li class="tocline0">11.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.11">IANA Considerations</a></li><li class="tocline0">12.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul class="toc"><li class="tocline1">12.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li class="tocline1">12.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li class="tocline0"><a href="#rfc.authors">Author's Address</a></li><li class="tocline0">A.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.A">Acknowledgements</a></li><li class="tocline0">B.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.B">Frequently Asked Questions</a></li><li class="tocline0">C.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.C">Changes</a></li></ul><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction</h1><p id="rfc.section.1.p.1">HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> added pipelining -- that is, the ability to have more than one outstanding request on a connection at a particular time -- to improve performance when many requests need to be made (e.g., when an HTML page references several images).</p><p id="rfc.section.1.p.2">Although not usable in all circumstances (POST and other non-idempotent requests cannot be pipelined), for the common case of Web browsing, pipelining seems at first like a broadly useful improvement -- especially since the number of TCP connections browsers and servers can use for a given interaction is limited, and especially where there is noticeable latency present.</p><p id="rfc.section.1.p.3">Indeed, in constrained applications of HTTP such as Subversion, pipelining has been shown to improve end-user perceived latency considerably.</p><p id="rfc.section.1.p.4">However, pipelining is not broadly used on the Web today; while most (but not all) servers and intermediaries support pipelining (to varying degrees), only one major Web browser uses it in its default configuration, and that implementation is reported to use a number of proprietary heuristics to determine when it is safe to pipeline.</p><p id="rfc.section.1.p.5">This memo characterises issues currently encountered in the use of HTTP pipelining, and suggests mechanisms that are designed to make its use more reliable and safe for browsers.</p><p id="rfc.section.1.p.6">Note that this memo does not suggest drastic changes to HTTP, nor does it require that intermediaries change to better support pipelining. Instead, it takes the position that removing the responsibility for making pipelining decisions from browsers, as well as reduce associated risks for browsers, we make it more likely that browsers will support it.</p><p id="rfc.section.1.p.7">This memo should be discussed on the ietf-http-wg@w3.org mailing list, although it is not a work item of the HTTPbis WG. Reviewers are encouraged to pay particular attention to items marked FEEDBACK.</p><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;Requirements</h1><p id="rfc.section.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;HTTP Pipelining Issues</h1><p id="rfc.section.3.p.1">Anecdotal evidence suggests there are a number of reasons why clients don't use HTTP pipelining by default. Briefly, they are: </p><ol><li>Balking Servers - server implementations can stall pipelined requests, or close their connection when the client attempts to pipeline. This is one of the most commonly cited problems.</li><li>Confused Servers - a few server implementations can respond to pipelined requests in the wrong order. Even fewer might corrupt the actual responses. Because this has security implications (consider multiple users behind such a proxy, or multiple tabs in a browser), this is very concerning.</li><li>Head-of-Line Blocking - Clients don't have enough information about what is useful to pipeline. A given response may take an inordinate amount of time to generate, and/or be large enough to block subsequent responses. Clients who pipeline may face worse performance if they stack requests behind such an expensive request.</li></ol><p id="rfc.section.3.p.2">Note that here, "servers" can also include proxies and other intermediaries, including so-called "transparent" proxies (also known as intercepting proxies).</p><p id="rfc.section.3.p.3">The remainder of this memo proposes mechanisms that can be used to mitigate one or more of these problems; not all of them will survive discussion and implementation.</p><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;Blacklisting Origin Servers</h1><p id="rfc.section.4.p.1">To address balking and confused origin servers, a client SHOULD maintain a blacklist of origins that it does not attempt pipelining with.</p><p id="rfc.section.4.p.2">Such a blacklist MAY be populated by external information (e.g., a list of known-bad servers maintained by the browser vendor), and when pipelining has been detected to fail to the origin.</p><h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;Discovering Faulty Proxies</h1><p id="rfc.section.5.p.1">When a balking or confused server is a proxy, pipelining won't work for any requests sent through it. Therefore, clients SHOULD test the network for such proxies periodically.</p><p id="rfc.section.5.p.2">This can be done by sending pipelined requests to a known server, and examining the responses for errors.</p><p id="rfc.section.5.p.3">For example, if the ExampleBrowser implementation wishes to probe for faulty proxies, it can send a series of requests to "http://browser.example.com/pipeline-test/" and subresources. If the bodies of the resulting responses deviate from those it expects in any way, it is reasonable to assume that a faulty proxy is present, and pipelining SHOULD NOT be used through it.</p><p id="rfc.section.5.p.4">RECOMMENDED measures in such tests include:</p><ul><li>Sending a non-trivial number of pipelined requests (e.g., 10)</li><li>Sending multiple pipelined requests in the same packet</li><li>Inserting request bodies with various sizes</li><li>Assuring that caching is disabled, so that requests are end-to-end</li><li>Sending a variety of responses types that includes 100 and 304 responses</li><li>Examining responses to assure that they all appear in the correct order</li><li>Examining received requests and responses to assure that they aren't unduly modified</li></ul><p id="rfc.section.5.p.6">These tests SHOULD be performed by clients (both user agent and proxy) upon startup, as well as periodically afterwards to assure that a new intercepting proxy hasn't been interposed. They MAY be performed after a pipelining problem is detected, to determine whether the issue is proxy- related.</p><p id="rfc.section.5.p.7">See &lt;<a href="https://github.com/mnot/pipeline-surveyor">https://github.com/mnot/pipeline-surveyor</a>&gt; for an example implementation.</p><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;Correlating Responses</h1><p id="rfc.section.6.p.1">HTTP relies on the context of the connection to associate a given request with its intended response. In HTTP/1.0, this was a reasonable assumption, since only one request could be outstanding at a given time, and each request had exactly one response.</p><p id="rfc.section.6.p.2">HTTP/1.1 made associating requests and responses in a given connection more complex (and therefore fault-prone). Not only does pipelining mean that multiple requests can be outstanding, but also the 1xx series of response status codes introduce the possibility of multiple response messages (syntactically) being associated with a single request.</p><p id="rfc.section.6.p.3">To improve the client's ability to correlate responses with their requests and identify confused origin and proxy servers (as well as serve other potential use cases), this memo introduces the "Assoc-Req" response header field.</p><div id="rfc.figure.u.1"></div><pre>
  294
+Assoc-Req   = "Assoc-Req" ":" OWS Assoc-Req-v
  295
+Assoc-Req-v = Method SP absolute-URI
  296
+</pre><p id="rfc.section.6.p.5">The field-value of the Assoc-Req header field is the method and effective request URI of the request associated with the response that it appears in. The URI used MUST be generated using the algorithm for finding the Effective Request URI in <a href="#I-D.ietf-httpbis-p1-messaging"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[I-D.ietf-httpbis-p1-messaging]</cite></a>. The header field MUST NOT be generated by proxies.</p><p id="rfc.section.6.p.6">For example, given the following request over port 80:</p><div id="rfc.figure.u.2"></div><pre>
  297
+GET /foo?it HTTP/1.1
  298
+Host: www.example.com
  299
+</pre><p id="rfc.section.6.p.8">the appropriate Assoc-Req header field would be:</p><div id="rfc.figure.u.3"></div><pre>
  300
+Assoc-Req: GET http://www.example.com/foo?it
  301
+</pre><p id="rfc.section.6.p.10">Note that the Assoc-Req header field is not a perfectly reliable identifier for the request associated with a response; for example, it does not incorporate the selecting headers for content negotiation <a href="#I-D.ietf-httpbis-p6-cache"><cite title="HTTP/1.1, part 6: Caching">[I-D.ietf-httpbis-p6-cache]</cite></a>, nor does it differentiate request bodies, when present. However, for the purposes of making pipelining more reliable, it is sufficient.</p><p id="rfc.section.6.p.11">A client wishing to use the Assoc-Req response header field to aid in identifying problems in pipelining can compare its values to those of the request that it believes it to be associated with (based upon HTTP's message parsing rules, defined in <a href="#I-D.ietf-httpbis-p1-messaging"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[I-D.ietf-httpbis-p1-messaging]</cite></a>). If either the method or the URI differ, it indicates that there may be a pipelining-related issue, and the origin server (identified by its (host, port) tuple) SHOULD be blacklisted.</p><p id="rfc.section.6.p.12">A client MAY choose to blacklist any origin server that does not send the Assoc-Req header.</p><p id="rfc.section.6.p.13">FEEDBACK: Omitting the URI scheme and authority (i.e., just making it the path and query components) would make the header easier to generate and avoid some false positives (e.g., when a "reverse proxy" or other URI rewriter is present), but may fail to identify cases where two requests are confused (consider requests for "http://example.com/style.css" and "https://foo.example.net/style.css").</p><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;Hinting Pipelinable Content</h1><p id="rfc.section.7.p.1">It's necessary to assist clients in determining what requests are suitable for pipelining, so that the sole responsibility for deciding what and when to pipeline isn't theirs. This can be done through origin server hinting.</p><p id="rfc.section.7.p.2">Such hints indicates URLs that, when dereferenced, will likely not incur significant latency on the server in generating the response, nor significant latency on the network in transferring the response.</p><p id="rfc.section.7.p.3">What is "significant" is determined by the server. Clients will use these hints to determine what request(s) it is safe to pipeline something else after.</p><p id="rfc.section.7.p.4">For example, if "http://example.com/a" is hinted, a client can be more confident pipelining another request (e.g., to "http://example.com/b") on the same connection afterwards.</p><p id="rfc.section.7.p.5">There are several possible ways that content could be hinted, including: </p><ul><li>The "quick" link relation type can appear on individual HTML elements such as "img", "script" and "link" to indicate that the link they contain has low overhead.</li><li>A similar link relation could also be used in the HTTP link header to indicate "quick" links within the response in a format-neutral way.</li><li>A server can indicate that all its resources are suitable for pipelining by returning a successful response status code (2xx) to requests for the path "/.well-known/pipeline". In the future, a format available at this location could give more fine-grained information.</li></ul><p id="rfc.section.7.p.6">FEEDBACK: thoughts on the suitability of these hinting mechanisms is encouraged, so that the list can eventually be narrowed down.</p><p id="rfc.section.7.p.7">A user agent MAY have a policy of only pipelining to hinted resources.</p><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;Indicating Blocking Responses</h1><p id="rfc.section.8.p.1">An alternate way to avoid head-of-line blocking is for the origin server to aggressively indicate when a request would block.</p><p id="rfc.section.8.p.2">This can be done by using a new HTTP status code, 430 WOULD BLOCK.</p><p id="rfc.section.8.p.3">The meaning of "would block" is defined by the server; e.g., it may return this code when the response is known to be over a certain size, or when the code to generate the response is known to take a long time to execute.</p><p id="rfc.section.8.p.4">When a client (user agent or intermediary) receives a 430 WOULD BLOCK, it SHOULD resubmit the associated request on a new or idle connection.</p><p id="rfc.section.8.p.5">An origin server MUST NOT send a 430 WOULD BLOCK status code to clients that do not include a "PWB: 1" (mnemonic: Pipelining Would Block) request header. User Agents that support the status code SHOULD send this header, and intermediaries that are willing to handle its processing MAY append it to requests that do not already include it.</p><p id="rfc.section.8.p.6">A cache MUST NOT store a 430 WOULD BLOCK response, and origin servers SHOULD mark them as explicitly uncacheable (e.g., with Cache-Control: no-store).</p><p id="rfc.section.8.p.7">FEEDBACK: This is a relatively new idea; thoughts? In some ways it's easier to deploy, but it does add a certain amount of latency to requests that block. Theoretically, a Location header could be added to redirect the client to a place where the generated response will be waiting (if the blocking is caused by server-side think time), but this may be impractical to implement.</p><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;Handling Pipelining Problems</h1><p id="rfc.section.9.p.1">Upon encountering an indication of pipelining problems with a particular response (e.g., an incorrect Assoc-Req field-value, a pipelined response that stalls), user agents SHOULD discard the response in question, all subsequent responses on the same connection, and close the connection. Unsatisfied requests can be resubmitted, without pipelining, and the implementation can choose not to use pipelining to the same server in the future (see "Blacklisting Origin Servers").</p><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;Security Considerations</h1><p id="rfc.section.10.p.1">TBD</p><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;IANA Considerations</h1><p id="rfc.section.11.p.1">TBD</p><h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References</h1><h2 id="rfc.references.1"><a href="#rfc.section.12.1" id="rfc.section.12.1">12.1</a> Normative References</h2><table><tr><td class="reference"><b id="I-D.ietf-httpbis-p1-messaging">[I-D.ietf-httpbis-p1-messaging]</b></td><td class="top">Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, &#8220;<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>&#8221;, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-12 (work in progress), October&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC2119">[RFC2119]</b></td><td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, &#8220;<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>&#8221;, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.</td></tr></table><h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References</h2><table><tr><td class="reference"><b id="I-D.ietf-httpbis-p6-cache">[I-D.ietf-httpbis-p6-cache]</b></td><td class="top">Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, &#8220;<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-12">HTTP/1.1, part 6: Caching</a>&#8221;, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-12 (work in progress), October&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC2616">[RFC2616]</b></td><td class="top"><a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="World Wide Web Consortium">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="World Wide Web Consortium">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">T. Berners-Lee</a>, &#8220;<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>&#8221;, RFC&nbsp;2616, June&nbsp;1999.</td></tr></table><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1><address class="vcard"><span class="vcardline"><span class="fn">Mark Nottingham</span><span class="n hidden"><span class="family-name">Nottingham</span><span class="given-name">Mark</span></span></span><span class="vcardline">EMail: <a href="mailto:mnot@mnot.net"><span class="email">mnot@mnot.net</span></a></span><span class="vcardline">URI: <a href="http://www.mnot.net/" class="url">http://www.mnot.net/</a></span></address></div><h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements</h1><p id="rfc.section.A.p.1">Thanks to Ilya Grigorik, Anirban Kundu, Patrick McManus and Julian Reschke. The author takes all responsibility for errors and omissions.</p><h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;Frequently Asked Questions</h1><p id="rfc.section.B.p.1">Isn't full multiplexing better?</p><p id="rfc.section.B.p.2">While "full" multiplexing is theoretically better, pipelining -- once usable -- is adequate for almost all common Web browsing cases. Since the browser needs to download HTML first, it has an opportunity to receive hints about subsequent requests and pipeline them appropriately. Likewise, by far the most common case for multiplexing on the Web is when a large number of images and other page assets need to be fetched with GET; a perfect use of pipelining, provided that the client has enough information to avoid head-of-line blocking.</p><p id="rfc.section.B.p.3">Why not have the client generate a unique request identifier?</p><p id="rfc.section.B.p.4">While in some ways this would be easier than the approach that the Assoc-Req header takes, it would be more difficult to deploy, because existing caching proxies wouldn't be able to serve the correct identifier when using a cached response.</p><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;Changes</h1><p id="rfc.section.C.p.1">draft -00 to draft -01:</p><ul><li>Add guidelines for blacklisting</li><li>Remove advice on signature checking (for now)</li><li>Clarified problem statement</li><li>Rearranged</li><li>Added 430 WOULD BLOCK</li></ul></body></html>
560  http-pipeline/draft-nottingham-http-pipeline-01.txt
... ...
@@ -0,0 +1,560 @@
  1
+
  2
+
  3
+
  4
+Network Working Group                                      M. Nottingham
  5
+Internet-Draft                                            March 13, 2011
  6
+Intended status: Informational
  7
+Expires: September 14, 2011
  8
+
  9
+
  10
+             Making HTTP Pipelining Usable on the Open Web
  11
+                   draft-nottingham-http-pipeline-01
  12
+
  13
+Abstract
  14
+
  15
+   Pipelining was added to HTTP/1.1 as a means of improving the
  16
+   performance of persistent connections in common cases.  While it is
  17
+   deployed in some limited circumstances, it is not widely used by
  18
+   clients on the open Internet.  This memo suggests some measures
  19
+   designed to make it more possible for clients to reliably and safely
  20
+   use HTTP pipelining in these situations.
  21
+
  22
+Status of this Memo
  23
+
  24
+   This Internet-Draft is submitted in full conformance with the
  25
+   provisions of BCP 78 and BCP 79.
  26
+
  27
+   Internet-Drafts are working documents of the Internet Engineering
  28
+   Task Force (IETF).  Note that other groups may also distribute
  29
+   working documents as Internet-Drafts.  The list of current Internet-
  30
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
  31
+
  32
+   Internet-Drafts are draft documents valid for a maximum of six months
  33
+   and may be updated, replaced, or obsoleted by other documents at any
  34
+   time.  It is inappropriate to use Internet-Drafts as reference
  35
+   material or to cite them other than as "work in progress."
  36
+
  37
+   This Internet-Draft will expire on September 14, 2011.
  38
+
  39
+Copyright Notice
  40
+
  41
+   Copyright (c) 2011 IETF Trust and the persons identified as the
  42
+   document authors.  All rights reserved.
  43
+
  44
+   This document is subject to BCP 78 and the IETF Trust's Legal
  45
+   Provisions Relating to IETF Documents
  46
+   (http://trustee.ietf.org/license-info) in effect on the date of
  47
+   publication of this document.  Please review these documents
  48
+   carefully, as they describe your rights and restrictions with respect
  49
+   to this document.  Code Components extracted from this document must
  50
+   include Simplified BSD License text as described in Section 4.e of
  51
+   the Trust Legal Provisions and are provided without warranty as
  52
+
  53
+
  54
+
  55
+Nottingham             Expires September 14, 2011               [Page 1]
  56
+
  57
+Internet-Draft        HTTP Pipelining Enhancements            March 2011
  58
+
  59
+
  60
+   described in the Simplified BSD License.
  61
+
  62
+
  63
+Table of Contents
  64
+
  65
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  66
+   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
  67
+   3.  HTTP Pipelining Issues . . . . . . . . . . . . . . . . . . . .  4
  68
+   4.  Blacklisting Origin Servers  . . . . . . . . . . . . . . . . .  4
  69
+   5.  Discovering Faulty Proxies . . . . . . . . . . . . . . . . . .  4
  70
+   6.  Correlating Responses  . . . . . . . . . . . . . . . . . . . .  5
  71
+   7.  Hinting Pipelinable Content  . . . . . . . . . . . . . . . . .  7
  72
+   8.  Indicating Blocking Responses  . . . . . . . . . . . . . . . .  7
  73
+   9.  Handling Pipelining Problems . . . . . . . . . . . . . . . . .  8
  74
+   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  8
  75
+   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
  76
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  77
+     12.1.  Normative References  . . . . . . . . . . . . . . . . . .  9
  78
+     12.2.  Informative References  . . . . . . . . . . . . . . . . .  9
  79
+   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . .  9
  80
+   Appendix B.  Frequently Asked Questions  . . . . . . . . . . . . .  9
  81
+   Appendix C.  Changes . . . . . . . . . . . . . . . . . . . . . . . 10
  82
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
  83
+
  84
+
  85
+
  86
+
  87
+
  88
+
  89
+
  90
+
  91
+
  92
+
  93
+
  94
+
  95
+
  96
+
  97
+
  98
+
  99
+
  100
+
  101
+
  102
+
  103
+
  104
+
  105
+
  106
+
  107
+
  108
+
  109
+
  110
+
  111
+Nottingham             Expires September 14, 2011               [Page 2]
  112
+
  113
+Internet-Draft        HTTP Pipelining Enhancements            March 2011
  114
+
  115
+
  116
+1.  Introduction
  117
+
  118
+   HTTP/1.1 [RFC2616] added pipelining -- that is, the ability to have
  119
+   more than one outstanding request on a connection at a particular
  120
+   time -- to improve performance when many requests need to be made
  121
+   (e.g., when an HTML page references several images).
  122
+
  123
+   Although not usable in all circumstances (POST and other non-
  124
+   idempotent requests cannot be pipelined), for the common case of Web
  125
+   browsing, pipelining seems at first like a broadly useful improvement
  126
+   -- especially since the number of TCP connections browsers and
  127
+   servers can use for a given interaction is limited, and especially
  128
+   where there is noticeable latency present.
  129
+
  130
+   Indeed, in constrained applications of HTTP such as Subversion,
  131
+   pipelining has been shown to improve end-user perceived latency
  132
+   considerably.
  133
+
  134
+   However, pipelining is not broadly used on the Web today; while most
  135
+   (but not all) servers and intermediaries support pipelining (to
  136
+   varying degrees), only one major Web browser uses it in its default
  137
+   configuration, and that implementation is reported to use a number of
  138
+   proprietary heuristics to determine when it is safe to pipeline.
  139
+
  140
+   This memo characterises issues currently encountered in the use of
  141
+   HTTP pipelining, and suggests mechanisms that are designed to make
  142
+   its use more reliable and safe for browsers.
  143
+
  144
+   Note that this memo does not suggest drastic changes to HTTP, nor
  145
+   does it require that intermediaries change to better support
  146
+   pipelining.  Instead, it takes the position that removing the
  147
+   responsibility for making pipelining decisions from browsers, as well
  148
+   as reduce associated risks for browsers, we make it more likely that
  149
+   browsers will support it.
  150
+
  151
+   This memo should be discussed on the ietf-http-wg@w3.org mailing
  152
+   list, although it is not a work item of the HTTPbis WG.  Reviewers
  153
+   are encouraged to pay particular attention to items marked FEEDBACK.
  154
+
  155
+
  156
+2.  Requirements
  157
+
  158
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  159
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  160
+   document are to be interpreted as described in [RFC2119].
  161
+
  162
+
  163
+
  164
+
  165
+
  166
+
  167
+Nottingham             Expires September 14, 2011               [Page 3]
  168
+
  169
+Internet-Draft        HTTP Pipelining Enhancements            March 2011
  170
+
  171
+
  172
+3.  HTTP Pipelining Issues
  173
+
  174
+   Anecdotal evidence suggests there are a number of reasons why clients
  175
+   don't use HTTP pipelining by default.  Briefly, they are:
  176
+   1.  Balking Servers - server implementations can stall pipelined
  177
+       requests, or close their connection when the client attempts to
  178
+       pipeline.  This is one of the most commonly cited problems.
  179
+   2.  Confused Servers - a few server implementations can respond to
  180
+       pipelined requests in the wrong order.  Even fewer might corrupt
  181
+       the actual responses.  Because this has security implications
  182
+       (consider multiple users behind such a proxy, or multiple tabs in
  183
+       a browser), this is very concerning.
  184
+   3.  Head-of-Line Blocking - Clients don't have enough information
  185
+       about what is useful to pipeline.  A given response may take an
  186
+       inordinate amount of time to generate, and/or be large enough to
  187
+       block subsequent responses.  Clients who pipeline may face worse
  188
+       performance if they stack requests behind such an expensive
  189
+       request.
  190
+
  191
+   Note that here, "servers" can also include proxies and other
  192
+   intermediaries, including so-called "transparent" proxies (also known
  193
+   as intercepting proxies).
  194
+
  195
+   The remainder of this memo proposes mechanisms that can be used to
  196
+   mitigate one or more of these problems; not all of them will survive
  197
+   discussion and implementation.
  198
+
  199
+
  200
+4.  Blacklisting Origin Servers
  201
+
  202
+   To address balking and confused origin servers, a client SHOULD
  203
+   maintain a blacklist of origins that it does not attempt pipelining
  204
+   with.
  205
+
  206
+   Such a blacklist MAY be populated by external information (e.g., a
  207
+   list of known-bad servers maintained by the browser vendor), and when
  208
+   pipelining has been detected to fail to the origin.
  209
+
  210
+
  211
+5.  Discovering Faulty Proxies
  212
+
  213
+   When a balking or confused server is a proxy, pipelining won't work
  214
+   for any requests sent through it.  Therefore, clients SHOULD test the
  215
+   network for such proxies periodically.
  216
+
  217
+   This can be done by sending pipelined requests to a known server, and
  218
+   examining the responses for errors.
  219
+
  220
+
  221
+
  222
+
  223
+Nottingham             Expires September 14, 2011               [Page 4]
  224
+
  225
+Internet-Draft        HTTP Pipelining Enhancements            March 2011
  226
+
  227
+
  228
+   For example, if the ExampleBrowser implementation wishes to probe for
  229
+   faulty proxies, it can send a series of requests to
  230
+   "http://browser.example.com/pipeline-test/" and subresources.  If the
  231
+   bodies of the resulting responses deviate from those it expects in
  232
+   any way, it is reasonable to assume that a faulty proxy is present,
  233
+   and pipelining SHOULD NOT be used through it.
  234
+
  235
+   RECOMMENDED measures in such tests include:
  236
+
  237
+   o  Sending a non-trivial number of pipelined requests (e.g., 10)
  238
+   o  Sending multiple pipelined requests in the same packet
  239
+   o  Inserting request bodies with various sizes
  240
+   o  Assuring that caching is disabled, so that requests are end-to-end
  241
+   o  Sending a variety of responses types that includes 100 and 304
  242
+      responses
  243
+   o  Examining responses to assure that they all appear in the correct
  244
+      order
  245
+   o  Examining received requests and responses to assure that they
  246
+      aren't unduly modified
  247
+
  248
+   These tests SHOULD be performed by clients (both user agent and
  249
+   proxy) upon startup, as well as periodically afterwards to assure
  250
+   that a new intercepting proxy hasn't been interposed.  They MAY be
  251
+   performed after a pipelining problem is detected, to determine
  252
+   whether the issue is proxy- related.
  253
+
  254
+   See <https://github.com/mnot/pipeline-surveyor> for an example
  255
+   implementation.
  256
+
  257
+
  258
+6.  Correlating Responses
  259
+
  260
+   HTTP relies on the context of the connection to associate a given
  261
+   request with its intended response.  In HTTP/1.0, this was a
  262
+   reasonable assumption, since only one request could be outstanding at
  263
+   a given time, and each request had exactly one response.
  264
+
  265
+   HTTP/1.1 made associating requests and responses in a given
  266
+   connection more complex (and therefore fault-prone).  Not only does
  267
+   pipelining mean that multiple requests can be outstanding, but also
  268
+   the 1xx series of response status codes introduce the possibility of
  269
+   multiple response messages (syntactically) being associated with a
  270
+   single request.
  271
+
  272
+   To improve the client's ability to correlate responses with their
  273
+   requests and identify confused origin and proxy servers (as well as
  274
+   serve other potential use cases), this memo introduces the "Assoc-
  275
+   Req" response header field.
  276
+
  277
+
  278
+
  279
+Nottingham             Expires September 14, 2011               [Page 5]
  280
+
  281
+Internet-Draft        HTTP Pipelining Enhancements            March 2011
  282
+
  283
+
  284
+   Assoc-Req   = "Assoc-Req" ":" OWS Assoc-Req-v
  285
+   Assoc-Req-v = Method SP absolute-URI
  286
+
  287
+   The field-value of the Assoc-Req header field is the method and
  288
+   effective request URI of the request associated with the response
  289
+   that it appears in.  The URI used MUST be generated using the
  290
+   algorithm for finding the Effective Request URI in
  291
+   [I-D.ietf-httpbis-p1-messaging].  The header field MUST NOT be
  292
+   generated by proxies.
  293
+
  294
+   For example, given the following request over port 80:
  295
+
  296
+   GET /foo?it HTTP/1.1
  297
+   Host: www.example.com
  298
+
  299
+   the appropriate Assoc-Req header field would be:
  300
+
  301
+   Assoc-Req: GET http://www.example.com/foo?it
  302
+
  303
+   Note that the Assoc-Req header field is not a perfectly reliable
  304
+   identifier for the request associated with a response; for example,
  305
+   it does not incorporate the selecting headers for content negotiation
  306
+   [I-D.ietf-httpbis-p6-cache], nor does it differentiate request
  307
+   bodies, when present.  However, for the purposes of making pipelining
  308
+   more reliable, it is sufficient.
  309
+
  310
+   A client wishing to use the Assoc-Req response header field to aid in
  311
+   identifying problems in pipelining can compare its values to those of
  312
+   the request that it believes it to be associated with (based upon
  313
+   HTTP's message parsing rules, defined in
  314
+   [I-D.ietf-httpbis-p1-messaging]).  If either the method or the URI
  315
+   differ, it indicates that there may be a pipelining-related issue,
  316
+   and the origin server (identified by its (host, port) tuple) SHOULD
  317
+   be blacklisted.
  318
+
  319
+   A client MAY choose to blacklist any origin server that does not send
  320
+   the Assoc-Req header.
  321
+
  322
+   FEEDBACK: Omitting the URI scheme and authority (i.e., just making it
  323
+   the path and query components) would make the header easier to
  324
+   generate and avoid some false positives (e.g., when a "reverse proxy"
  325
+   or other URI rewriter is present), but may fail to identify cases
  326
+   where two requests are confused (consider requests for
  327
+   "http://example.com/style.css" and
  328
+   "https://foo.example.net/style.css").
  329
+
  330
+
  331
+
  332
+
  333
+
  334
+
  335
+Nottingham             Expires September 14, 2011               [Page 6]
  336
+
  337
+Internet-Draft        HTTP Pipelining Enhancements            March 2011
  338
+
  339
+
  340
+7.  Hinting Pipelinable Content
  341
+
  342
+   It's necessary to assist clients in determining what requests are
  343
+   suitable for pipelining, so that the sole responsibility for deciding
  344
+   what and when to pipeline isn't theirs.  This can be done through
  345
+   origin server hinting.
  346
+
  347
+   Such hints indicates URLs that, when dereferenced, will likely not
  348
+   incur significant latency on the server in generating the response,
  349
+   nor significant latency on the network in transferring the response.
  350
+
  351
+   What is "significant" is determined by the server.  Clients will use
  352
+   these hints to determine what request(s) it is safe to pipeline
  353
+   something else after.
  354
+
  355
+   For example, if "http://example.com/a" is hinted, a client can be
  356
+   more confident pipelining another request (e.g., to
  357
+   "http://example.com/b") on the same connection afterwards.
  358
+
  359
+   There are several possible ways that content could be hinted,
  360
+   including:
  361
+   o  The "quick" link relation type can appear on individual HTML
  362
+      elements such as "img", "script" and "link" to indicate that the
  363
+      link they contain has low overhead.
  364
+   o  A similar link relation could also be used in the HTTP link header
  365
+      to indicate "quick" links within the response in a format-neutral
  366
+      way.
  367
+   o  A server can indicate that all its resources are suitable for
  368
+      pipelining by returning a successful response status code (2xx) to
  369
+      requests for the path "/.well-known/pipeline".  In the future, a
  370
+      format available at this location could give more fine-grained
  371
+      information.
  372
+
  373
+   FEEDBACK: thoughts on the suitability of these hinting mechanisms is
  374
+   encouraged, so that the list can eventually be narrowed down.
  375
+
  376
+   A user agent MAY have a policy of only pipelining to hinted
  377
+   resources.
  378
+
  379
+
  380
+8.  Indicating Blocking Responses
  381
+
  382
+   An alternate way to avoid head-of-line blocking is for the origin
  383
+   server to aggressively indicate when a request would block.
  384
+
  385
+   This can be done by using a new HTTP status code, 430 WOULD BLOCK.
  386
+
  387
+   The meaning of "would block" is defined by the server; e.g., it may
  388
+
  389
+
  390
+
  391
+Nottingham             Expires September 14, 2011               [Page 7]
  392
+
  393
+Internet-Draft        HTTP Pipelining Enhancements            March 2011
  394
+
  395
+
  396
+   return this code when the response is known to be over a certain
  397
+   size, or when the code to generate the response is known to take a
  398
+   long time to execute.
  399
+
  400
+   When a client (user agent or intermediary) receives a 430 WOULD
  401
+   BLOCK, it SHOULD resubmit the associated request on a new or idle
  402
+   connection.
  403
+
  404
+   An origin server MUST NOT send a 430 WOULD BLOCK status code to
  405
+   clients that do not include a "PWB: 1" (mnemonic: Pipelining Would
  406
+   Block) request header.  User Agents that support the status code
  407
+   SHOULD send this header, and intermediaries that are willing to
  408
+   handle its processing MAY append it to requests that do not already
  409
+   include it.
  410
+
  411
+   A cache MUST NOT store a 430 WOULD BLOCK response, and origin servers
  412
+   SHOULD mark them as explicitly uncacheable (e.g., with Cache-Control:
  413
+   no-store).
  414
+
  415
+   FEEDBACK: This is a relatively new idea; thoughts?  In some ways it's
  416
+   easier to deploy, but it does add a certain amount of latency to
  417
+   requests that block.  Theoretically, a Location header could be added
  418
+   to redirect the client to a place where the generated response will
  419
+   be waiting (if the blocking is caused by server-side think time), but
  420
+   this may be impractical to implement.
  421
+
  422
+
  423
+9.  Handling Pipelining Problems
  424
+
  425
+   Upon encountering an indication of pipelining problems with a
  426
+   particular response (e.g., an incorrect Assoc-Req field-value, a
  427
+   pipelined response that stalls), user agents SHOULD discard the
  428
+   response in question, all subsequent responses on the same
  429
+   connection, and close the connection.  Unsatisfied requests can be
  430
+   resubmitted, without pipelining, and the implementation can choose
  431
+   not to use pipelining to the same server in the future (see
  432
+   "Blacklisting Origin Servers").
  433
+
  434
+
  435
+10.  Security Considerations
  436
+
  437
+   TBD
  438
+
  439
+
  440
+11.  IANA Considerations
  441
+
  442
+   TBD
  443
+
  444
+
  445
+
  446
+
  447
+Nottingham             Expires September 14, 2011               [Page 8]
  448
+
  449
+Internet-Draft        HTTP Pipelining Enhancements            March 2011
  450
+
  451
+
  452
+12.  References
  453
+
  454
+12.1.  Normative References
  455
+
  456
+   [I-D.ietf-httpbis-p1-messaging]
  457
+              Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
  458
+              Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke,
  459
+              "HTTP/1.1, part 1: URIs, Connections, and Message
  460
+              Parsing", draft-ietf-httpbis-p1-messaging-12 (work in
  461
+              progress), October 2010.
  462
+
  463
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  464
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
  465
+
  466
+12.2.  Informative References
  467
+
  468
+   [I-D.ietf-httpbis-p6-cache]
  469
+              Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
  470
+              Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke,
  471
+              "HTTP/1.1, part 6: Caching",
  472
+              draft-ietf-httpbis-p6-cache-12 (work in progress),
  473
+              October 2010.
  474
+
  475
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
  476
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
  477
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  478
+
  479
+
  480
+Appendix A.  Acknowledgements
  481
+
  482
+   Thanks to Ilya Grigorik, Anirban Kundu, Patrick McManus and Julian
  483
+   Reschke.  The author takes all responsibility for errors and
  484
+   omissions.
  485
+
  486
+
  487
+Appendix B.  Frequently Asked Questions
  488
+
  489
+   Isn't full multiplexing better?
  490
+
  491
+   While "full" multiplexing is theoretically better, pipelining -- once
  492
+   usable -- is adequate for almost all common Web browsing cases.
  493
+   Since the browser needs to download HTML first, it has an opportunity
  494
+   to receive hints about subsequent requests and pipeline them
  495
+   appropriately.  Likewise, by far the most common case for
  496
+   multiplexing on the Web is when a large number of images and other
  497
+   page assets need to be fetched with GET; a perfect use of pipelining,
  498
+   provided that the client has enough information to avoid head-of-line
  499
+   blocking.
  500
+
  501
+
  502
+
  503
+Nottingham             Expires September 14, 2011               [Page 9]
  504
+
  505
+Internet-Draft        HTTP Pipelining Enhancements            March 2011
  506
+
  507
+
  508
+   Why not have the client generate a unique request identifier?
  509
+
  510
+   While in some ways this would be easier than the approach that the
  511
+   Assoc-Req header takes, it would be more difficult to deploy, because
  512
+   existing caching proxies wouldn't be able to serve the correct
  513
+   identifier when using a cached response.
  514
+
  515
+
  516
+Appendix C.  Changes
  517
+
  518
+   draft -00 to draft -01:
  519
+
  520
+   o  Add guidelines for blacklisting
  521
+   o  Remove advice on signature checking (for now)
  522
+   o  Clarified problem statement
  523
+   o  Rearranged
  524
+   o  Added 430 WOULD BLOCK
  525
+
  526
+
  527
+Author's Address
  528
+
  529
+   Mark Nottingham
  530
+
  531
+   Email: mnot@mnot.net
  532
+   URI:   http://www.mnot.net/
  533
+
  534
+
  535
+
  536
+
  537
+
  538
+
  539
+
  540
+
  541
+
  542
+
  543
+
  544
+
  545
+
  546
+
  547
+
  548
+
  549
+
  550
+
  551
+
  552
+
  553
+
  554
+
  555
+
  556
+
  557
+
  558
+
  559
+Nottingham             Expires September 14, 2011              [Page 10]
  560
+

0 notes on commit 7e47fdc

Please sign in to comment.
Something went wrong with that request. Please try again.