Re: XHR LC comment: Accept header went from MUST NOT to SHOULD

Julian Reschke <julian.reschke@gmx.de> wrote:

> Stewart Brodie wrote:
> >> If a server can't cope with it (evidence, please!), fix it.
> > 
> > Some older versions of Microsoft IIS are the servers that I've come
> > across that fail to cope with it.  It is unrealistic to expect these to
> > be undeployed any time soon.  The comment in my code does not specify
> > version numbers - it simply indicates that a lack of an Accept header
> > causes some versions of IIS to return a None Match error.  On that
> > basis, and because sending "Accept: */*" fixes the problem, I am
> > assuming that the fault lies in the content negotation code.
> 
> Well, the client alway can set "Accept" to "*/*" if it needs to
> communicate with that server.

That was my original point: the XHR LC explicitly prohibited the UA from
adding an Accept header.  That's why I requested that it be changed from a
MUST NOT requirement.  As far as I'm concerned, the UA has to be free to
implement such workarounds, especially any that are semantically
transparent.


> Please do not burden the spec with workarounds when it is clearly *not*
> required.

I don't think it is being specified.  My original suggestion was to add
something saying that if the client chose to add the header then it SHOULD
use "*/*" as the value.  Anne already rejected this on the grounds that
existing desktop browsers send arbitrary values for the header.  I don't
like that situation (I think those browsers are simply broken), but given
that the desktop browsers aren't going to change to comply, accepted that it
could be left unspecified.


-- 
Stewart Brodie
Software Engineer
ANT Software Limited

Received on Monday, 19 May 2008 10:48:20 UTC