W3C home > Mailing lists > Public > public-webapi@w3.org > March 2008

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 11 Mar 2008 07:41:55 -0700
To: Kris Zyp <kzyp@sitepen.com>
Message-Id: <3E2E7C02-A9C0-4A7C-A689-23BE28FA5377@apple.com>
Cc: Morgan L <morganl.webkit@yahoo.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, public-webapi@w3.org


On Mar 11, 2008, at 7:00 AM, Kris Zyp wrote:

>>> 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"):

As a browser implementor, I don't think I would find this more useful  
than a boolean property indicating a connection is likely to be long- 
lived. I can't imagine doing anything more complicated than picking a  
threshold value to decide whether to count a request towards the  
connection limit and whether to consider pipelining requests on its  
connection. If all implementors did this, we'd likely end up with  
somewhat different threshold values, which would be unfortunate.

Also, I'm skeptical that authors can estimate request latency with  
anything near that kind of precision. Thus, it is likely to be an  
unreliable source of information, meaning that the details of the  
value couldn't be trusted anyway, and even a high-low threshold might  
be unreliable. But most authors know if their XHR connection is  
intended to be used persistently, so the one bit of info would be more  
trustworthy.

Are there any implementors who would find an estimate of the request  
latency more useful than a boolean "likely to be persistent" indicator?

Regards,
Maciej
Received on Tuesday, 11 March 2008 14:42:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 March 2008 14:42:18 GMT