Pipelining Control Proposal

Pipelining Control

HTTP Pipelining is when more than one outstanding request is sent over a 
single TCP connection, and it was introduced in HTTP 1.1. This 
proposal defines that XHR objects should be able to control whether or not 
they are pipelined. A "pipeline" property would be added to the XHR object. 
If pipeline property is set to true, when send is called, the XHR request 
SHOULD be pipelined over one of the currently active connection, even if all 
connections to the target server are currently waiting for a response. That is,  
the request should be pipelined if necessary to send it immediately. If 
there is an available connection is alive, but no responses are waiting, the 
request should be sent on this connection (just as a non-pipelined request 
would be). If the pipeline property is set to false, the XHR request SHOULD 
NOT be pipelined even if the user agent supports and would otherwise pipeline 
the request. The pipeline property may also be set to another XHR object 
with an open connection, in which case the request should be pipelined on 
that specific TCP connection. For example:

var xhr1 = new XMLHttpRequest();
xhr1.open("GET","/resource1",true);
xhr1.send(null);

var xhr2 = new XMLHttpRequest();
xhr2.open("GET","/resource2",true);
xhr2.pipeline = xhr1;
xhr2.send(null);

In this example, both requests should be sent over the same TCP connection. 
The GET for resource1 should be sent and the GET for resource2 should be 
pipelined behind the first request on the same connection.

If a connection has been marked as an "extra connection" with the extraConnection
property on the XHR object (see the extra connection proposal), that connection
should not be used for pipelined requests unless another XHR request explicitly 
specifies that connection, in which case that XHR request SHOULD be pipelined 
on that connection. (This is because the extra connection request is generally to be used
for long-lived responses that are kept open for server-sent messages. Requests that 
are sent behind such a request may never receive a response, which should not be 
the default behavior, but may be explicitly chosen to achieve full asynchronous 
duplex communication on a single TCP connection, a highly valuable capability 
channels with server-sent messages.)

If a network error occurs while servicing a request, any pipelined requests that are 
queued behind the first request SHOULD NOT automatically be retried by the user 
agent. A network error in response to the first request should cause an error 
condition for both the first XHR object and all subsequent pipelined XHR objects 
per normal XHR behavior. It is the responsible of the application author to retry 
the request if desired.

Note that RFC 2616 states that non-idempotent methods should not be 
pipelined. However, this SHOULD NOT be enforced by the user agent. Authors should 
follow the recommendation of RFC 2616, but if they do not and choose to 
pipeline a non-idempotent request, the user agent should oblige.