W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

Re: Pipelining Control Proposal

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 19 Feb 2008 10:26:17 -0800
Message-ID: <47BB1F49.5070202@sicking.cc>
To: Kris Zyp <kzyp@sitepen.com>
CC: public-webapi@w3.org, Mark Baker <distobj@acm.org>

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.
Received on Tuesday, 19 February 2008 18:29:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:59 UTC