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: Mon, 10 Mar 2008 18:09:55 -0700
To: Kris Zyp <kzyp@sitepen.com>
Message-Id: <0522A9A2-6A8A-4C4E-9B54-64A08FC7879F@apple.com>
Cc: Morgan L <morganl.webkit@yahoo.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, public-webapi@w3.org

On Mar 10, 2008, at 7:34 AM, Kris Zyp wrote:

>> If the problem we are trying to solve is preventing potentially  
>> long- lived requests from blowing out the connection limit I think  
>> it would  be better to either:
>> 1) Add an explicit XHR property that indicates this request may be  
>> long-lived - this would not only bypass the connection limit but  
>> would also indicate to the UA that it should not pipeline other  
>> requests on  the same connection, if it supports pipelining.
>> 2) Never count XHR-initiated http requests towards the per-server  
>> connection limit.
>> .... not seem necessary for the goal of bypassing the connection  
>> limit on the UA side. And it seems that an explicit XHR property  
>> for this would  be more clear.
> I agree, I think #1 is the way to go. I don't like #2, because  
> connection limits really are valuable for minimizing server load,  
> and even can help prevent DOS attacks. As I just mentioned in the  
> other email, "Connection: close" is not an appropriate form of  
> advice, IMO. I think that an explicit property that provides advice  
> 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).

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:25 UTC