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

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

Received on Friday, 7 March 2008 23:53:21 UTC