- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 19 Feb 2008 10:26:17 -0800
- 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