I would be very worried about implementing this feature in a browser
since it runs a very big risk of creating websites that only work for
some users. I.e. for users with a direct connection to the server the
website would work fine, but for users sitting behind a proxy or a
firewall the site would break.
I doubt we can expect web authors to appropriately write fallback code
when in their testing pipelineing will work fine.
/ Jonas
Kris Zyp wrote:
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.
