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" <[EMAIL PROTECTED]>
To: "Kris Zyp" <[EMAIL PROTECTED]>
Cc: <[email protected]>; "Mark Baker" <[EMAIL PROTECTED]>
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.
