Re: XHR setRequestHeader("connection", "close") is bogusly rejected

>> for UAs is best approach, and that it should be a number-based  advice, 
>> not a boolean, so that it could be used more effectively and  flexibly in 
>> heuristic algorithms for making informed pipelining  decisions.
>
> Can you be more specific in what you mean about "number-based advice"? 
> (Apologies if you explained this in an earlier message, I tried  skimming 
> them and did not find a description).

I couldn't find my previous message in the archives, so I included below 
again (sorry about posting it again). Basically I was suggesting that a 
property (called "durability") could take a number (rather than a boolean), 
that would represent advice about how long the author expected the response 
to take. The user agent could utilize this advice in any way it sees fit. A 
number provides more information (a greater range of values) than a boolean, 
and it could effectively be used as weighting in user agent heuristics. The 
advice could be used by user agents to determine if the connection should be 
counted against the connection limit (if it is larger than a threshold), and 
it could used as advice for pipelining. The user agent is not required to 
respond in any certain way, but this is author provided advice, that the 
user agent may use in any way it desires.

The advantage of a number may be more clearly seen in a pipeline ordering 
example. Suppose I issue 4 requests, and I expect request A to take a few 
milliseconds, request B to take a half a second, request C to take a couple 
seconds, and request D could last indefinitely. I could set different 
durability values for each XHR request, and then the user agent could 
potentially use these values (possibly in combination with other 
information, like connection speed, proxy information, and so forth) to 
determine the order of pipelining:
xhrA.durability = 0.01;
xhrB.durability = 0.5;
xhrC.durability = 2;
xhrD.durability = 100;
In this situation, a browser may decide to send A and B on different 
connections, and send C as pipelined by request A. It may also choose to 
send D on completely separate connection and not count that against the 
connection limit. However, the advice does not require the user agent to 
take any specific action, the browser can weigh the advice in combination 
with other factors, depending on the situation. Anyway, here is the more 
detailed proposal I had sent out, I apologize if you have already received 
it/read it (it had a subject "Re: Pipelining Control Proposal"):


I wanted to propose another way to deal with the usability issues involved
with pipelining in combination with long-lived responses for the purposes of
server initiated messages. This is not an opposition to HTTP improvements
for declaring extra connection limits. I hope that happens for the broader
benefit that it provides and that HTTP improvements can solve the two-
connection limit probem, however as I articulate in the reasons at the
bottom,
HTTP improvements are simply not sufficient for avoiding pipeling issues,
and a simple mechanism for providing connection advise is critical as well.
I
believe this is a very minimalistic approach only adds a trivial amount of
complexity to the XMLHttpRequest spec and has almost zero required
implementation burden. The addition property defined here can be used
by user agents to deal with the problem of responses becoming indefinitely
queued due to being pipelined on a connection where a previous response
is never finished or simply takes a long time.

I propose that we have define a property called "durability" to the
XMLHttpRequest object, that can be assigned a positive number (x >= 0) by
authors that want to advise the user agent on how long they expect the given
request to last. A low value indicates that the request is expected to be
very quick and a high value indicates that the request is expected to take
longer. The "durability" property should default to 1, and so a value of 1
indicated a request with an average length of time. The durability property
can set and modified at any time before, during, or after a request. A user
agent is not required to behave in any particular way in response to the
durability property, it is simply a standard way for authors to provide
information about how long the response will probably take so that user
agents can utilize this information in making informed optimization
decisions,
and provide a means for intelligently avoiding indefinitely queued
requests/responses.

There are no requirements for how the user agent responds to this property,
but it is recommended that user agents use this information to help optimize
pipelining (and potentially connection limiting). The lower the durability
value,
the faster the request is likely to receive a response, and therefore the
corresponding connection is a better candidate for pipelining if that is
enabled in the user agent. The higher the durability value, the slower the
request is likely to receive a response, and therefore a high durability
value indicates that the connection is a poor candidate for pipelining. A
very high durability value (>100) indicates that the response may be so slow
in coming that it may be advisable for the connection to not be counted
against the two-connection limit (but this is not required, and I am
certainly
willing to concede HTTP as the primary advisor for connection limit
overriding).

This can be used by user agents to avoid the problem of responses
becoming indefinitely queued due to being pipelined on a connection where
a previous response is never finished.

Authors could also leverage user agents that follow the recommendations in
the proposal to create high-efficiency duplex communication channels (by
setting low durability values to attract pipelining).

Below is an example of usage of "durability":

var xhr1 = new XMLHttpRequest();
xhr1.open("GET","chat",true);
xhr1.durability = 1000; // this response may take a long time to return,
user agents may not want to pipeline here
xhr1.send(null);
....
xhr1.durability = 0.1; // now a fast response is indicated, this connection
may be a good candidate for pipelining now
var xhr2 = new XMLHttpRequest(); // the author has effectively recommend
that this request be pipelined on the connection used by xhr1
xhr2.open("GET","resource",true);
xhr2.send(null);

Once again this is not proposal for pipelining to be implemented through
XHR, nor a requirement that connection limits be increased, it is merely a
channel for advice to be passed that a user agent can utilize if it desires.
There are a number of reasons why allowing XHR advice is better than
completely deferring all advice to be provided by HTTP response headers:

1. The advice can be immediately available. Responses headers are not
available until received from the server, and in the meantime, advice can be
very relevant in helping to optimize pipelining. In particular, HTTP
response advice simply can not solve the problem of pipelining requests
behind long-lived responses resulting in indefinitely queued responses. If a
browser is pipelining requests, and a response is long-lived, it may attempt
to pipeling requests before receiving response headers indicating that
pipelining is not a good choice with the current response. The browser
simply has no information to suggest otherwise if it only comes through
response headers.

2. Advice can be altered during the life of the request/response. A response
header can only offer a single piece of advice, but XHR durability advice
can change, and the durability value can be lowered if the author knows that
a response will be received shortly. This can provide information that the
user agent may not be able to determine.

3. If browsers implemented pipelining and observed the recommendations for
pipelining, this opens the doors for true duplex communication on a single
TCP channel. Server-initiated messaging techniques are essentially efforts
to provide asynchronous duplex communication between the client and server.
However, currently all mechanisms for this rely on two TCP connections,
despite the fact TCP is fully duplex, and duplex communication is possible
with HTTP as well. I believe we would be remiss in not looking to the future
and considering how we can be moving towards a solution where authors can
achieve duplex communication efficiently; on a single connection. This
proposal provides that pathway. If there are any other mechanisms for doing
this, I would love to hear about them, but I do not know of any, and all
current techniques for server-initiating messaging (including the HTML 5
server-sent events) require two TCP connections for asynchronous duplex
communication (I would definitely be more interested in HTML5 server-sent
events if they did have some trajectory towards duplexity).

4. HTTP advice and XHR advice do need to be at odds. The
proposal is to have a standard property that can be used for heuristics, and
if HTTP adds a response header for advice, both sources of information can
be used for further improving heuristics.

5. This advice is useful for more than just indefinitely long-lived
responses
(as used with server initiated messaging), but could be extremely useful
in advising about responses that are known to take take a long time to be
processed on the server, so user agents could avoid pipelining behind
such requests.

6. Since this is simply an optional property for the sake of advice,
JavaScript
authors could immediately begin adding this advice to XHR requests, and
browser vendors could experiment with different ways of observing the
advice, at their own convenience, without having divergent APIs.
Experience based on implementation then might possibly lead to more
concrete requirements for observing the advice in the future.

This proposal addresses the issues from the "Pipelining Control" proposals
in a
very minimalistic form (and browsers could potentially use the advice to
alleviate
connection limit problems if they so desired), and the I hope this is a
reasonable compromise for improving the XHR.

Thanks,
Kris

Received on Tuesday, 11 March 2008 14:01:38 UTC