Re: Pipelining Control Proposal

Just about every feature available to web developers is non-uniformly 
available! Pipelining is vastly more broadly available than just about 
anything we have available to us. And arguments based on the unreliability 
of pipelining have still lacked any hard evidence. Dropping a proposal 
shouldn't be based on FUD.
The bottom line is even if some proxies don't handle pipelining, application 
authors should have the choice. Authors are aware of the risks and can make 
informed decisions when other browser features aren't uniformly available, 
and they should have the choice in this matter as well. We shouldn't just 
assume that all developers are stupid and just throw are hands up in despair 
that we can never have pipelining. That won't lead to progress. This is our 
best opportunity to have an inroad to pipelining, via consenting authors.
Kris
----- Original Message ----- 
From: "Jonas Sicking" <jonas@sicking.cc>
To: "Kris Zyp" <kzyp@sitepen.com>
Cc: <public-webapi@w3.org>; "Mark Baker" <distobj@acm.org>
Sent: Tuesday, February 19, 2008 11:26 AM
Subject: Re: Pipelining Control Proposal


>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:37:52 UTC