Julian Reschke <[EMAIL PROTECTED]> 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

> 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

Reply via email to