--- Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote:

> * Morgan L wrote:
> >In section 2 of
> http://www.w3.org/TR/XMLHttpRequest/,
> >it says that setRequestHeader should reject the
> >connection header.
> The purpose of these restrictions is to remind
> implementers that the
> user agent has to control certain headers for
> protocol integrity or
> other reasons, in other words, implementations
> should not blindy pass
> to the server whatever value a script might have set
> there.
> It should be perfectly permissable if the
> implementation instead of
> ignoring the attempt at setting some value takes the
> attempt under
> advisement when making its own decisions what to set
> the header to,
> in other words, the browser might well list close
> among the tokens
> after a script tried to set the header.
> I agree the current text does not convery this very
> well, do you have
> a suggestion how to editorially improve it? We can't
> simply "allow"
> this particular case as simply sending "Connection:
> close" can be wrong
> in many cases (see e.g. RFC 2616, section 13.5.1).

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.



Never miss a thing.  Make Yahoo your home page. 

Reply via email to