[Webkit-unassigned] [Bug 17682] XHR setRequestHeader("connection", "close") is bogusly rejected

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=17682





------- Comment #13 from morganl.webkit at yahoo.com  2008-03-08 21:43 PDT -------
(In reply to comment #11)
> By the time the origin server sends the response, it's too late to stop
> counting the request against the connection limit, since by assumption by then
> it has already been open for a while.

The origin server can send its response in chunks.  The first chunk could come
immediately and only contain the response headers.  Subsequent chunks could
come much later.  If the UA sees "connection: close" in that initial payload,
then it could recognize that the connection will not be persistent, and
therefore it can open a new connection if there are pending requests.  (This is
AFAIK the typical behavior of HTTP/1.1 clients.)  Anyways, this topic is a
tangent.


> So in conclusion, I think it may be a better design to make XHR-initiated
> requests always bypass the connection limit. 

This could be risky.  I have heard that some routers have trouble if they
receive too many SYN packets at once.  Not having a connection limit might
force web apps to do their own connection limiting, which could be problematic.
 I wish I had a reference for this anecdote :-/

Again, the point of this bug is to simply match existing browser behavior.  It
is a compat bug.  If there is a better long-term solution, involving nicer
APIs, then that's great, but I don't think it is mutually exclusive with
supporting the existing "API" for creating a XHR request that is not counted
against the browser's persistent connection limit.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.