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

--- Maciej Stachowiak <mjs@apple.com> wrote:

> 
> 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.


I agree that an explicit API would be more clear, but
my point in bringing this up was that there is an
"API" already supported by the majority browsers that
has been broken by the TR.  So, it seems like it would
be good for the TR to reflect reality first.

If an extra API makes sense, that's fine, but that
would seem to be something that should be additive.

Jonas: I agree that XHR users should not be able to
pass "connection: keep-alive".  You should see that
I've been arguing for "connection" only be allowed
with the "close" value.

--morgan


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Received on Sunday, 9 March 2008 05:31:45 UTC