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. Thoughts?
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.
Regards, Maciej
