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

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

From: Kris Zyp <kzyp@sitepen.com>
Date: Mon, 10 Mar 2008 08:26:00 -0600
Message-ID: <002f01c882ba$ab02e240$4200a8c0@kris>
To: "Jonas Sicking" <jonas@sicking.cc>, "Morgan L" <morganl.webkit@yahoo.com>
Cc: <public-webapi@w3.org>

>> However, there are web apps in existence (e.g., Gmail)
>> that set the "connection: close" header to inform the
>> user-agent that the HTTP transaction is going to take
>> a long time.  (This is also informative for the
>> server.)  This allows a user-agent to not count this
>> connection against the RFC 2616 recommended maximum of
>> 2 persistent connections per host.
As far as I can tell, Firefox is the only browser that regards "connection: 
close" as an indication that the connection should not be counted against 
the connection limit, and this behavior does _not_ follow the HTTP 
recommendation regarding connections. Section 8.1.4 states that:
  Clients that use persistent connections SHOULD limit the number of
   simultaneous connections that they maintain to a given server.
(All browsers use persistent connections, so all browsers are subject to the 
recommendation stated below)
   A single-user client SHOULD NOT maintain more than 2 connections with
   any server or proxy.
There is no mention of only maintaining two persistent connections, all 
connections (persistent or otherwise) are supposed to be counted against the 
connection limit. In addition, there is no reason why long-lived responses 
(those that shouldn't be counted against the connection limit) should have 
to have their TCP connection closed after the response is fully received. 
Therefore, I don't see "Connection: close" as an appropriate means for 
advising that connections should not be counted against connection limits.
Received on Monday, 10 March 2008 14:26:50 UTC

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