Re: Pipelining Control Proposal

An important difference is that most other features non-uniform across 
browser, not across users. A web developer can test the browsers they 
are interested in supporting. It's much harder for the developer to test 
the various user environments that are going to affect pipelining.

Don't get me wrong, I'd love pipelining as much as everyone else. I'm 
just not convinced that adding it through XMLHttpRequest is a solution 
that will help.

Another worry I have with the proposal is that I think XMLHttpRequest 
would be the wrong place to implement this. It's really a HTTP feature 
that should be implemented unrelated to XMLHttpRequest so that the rest 
of the browser can make use of it. Once we figure out a way to do it 
safely that is.

/ Jonas

Kris Zyp wrote:
> 
> 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 Wednesday, 20 February 2008 00:25:39 UTC