On Mar 7, 2008, at 3:02 PM, Morgan L wrote:

Ah, that make sense to me.  I think the current text
has caused major browser engines to "mistakenly" stop
supporting connection: close.  It is easy to blindly
implement whatever the "standards" say :-)

I think it would help if a caveat were added along the
lines of what you have written here.  I think the
"connection: close" example should be used to
demonstrate why it might be wise for a user-agent to
customize what request headers it rejects.

I'm not sure that section 13.5.2 implies that
"connection: close" can be wrong.  It is true that an
XHR users cannot assume that the origin server will
see the "connection: close" header, but it is still
always the case that the UA would see it.  And, in the
example that I provided, the goal is to tell the UA
that it does not need to count this request against
the max-persistent-connections-per-host limit.    At
least, I can't see how allowing XHR users to specify
"connection: close" can be regarded as harmful.


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.

Given that IE has increased their per-server connection limit to 6, and since the HTTP working group is considering dropping the connection limit as a formal spec requirement, I would probably advise #2 for WebKit and have commented to that effect in the bug you cited. From the spec point of view, I think #1 makes more sense since it may be inappropriate to require #2 (thoughts from other implementors welcome).

Requiring UAs to recognize "Connection: close" as a hint that the connection may be long-lived and should not count towards the limit is also possible as a variant of option 1. But I am not sure they should be required to also pass the header to the origin server. This does 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.


Reply via email to