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

[Laurens Holst]

Julian Reschke schreef:

Anne van Kesteren wrote:

On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst <[EMAIL PROTECTED]> wrote:

Why was this changed? Why should user agents pretend that they know what

kind of resource the user expects by setting an Accept header that is
unreliable? FWIW, Internet Explorer and Safari set the (reasonably


http://www.grauw.nl/blog/entry/470

acceptable */*), but it would be better to leave it out entirely. Also see:

It was pointed out by another Last Call comment that not setting the Accept header causes servers to break. Given the results above I suppose we could require that for XMLHttpRequest purposes it is at least always set to */*. Would that work?

Not setting the Accept header means the same thing as setting it to "*/*" (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.1.p.8>), so these servers simply are buggy.

I think it's better not to add more workarounds, but to let the XHR clients deal with these broken servers, by explicitly setting the header.

~Grauw

--
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.


begin:vcard
fn:Laurens Holst
n:Holst;Laurens
email;internet:[EMAIL PROTECTED]
tel;cell:(+31) 06-41765048
version:2.1
end:vcard

That would also be a possibility, however assuming that no current server exhibits this broken behaviour, there should then probably be a list of Server header identifiers which can be used to identify when to send Accept: */* and when to send nothing at all (assuming that the broken server(s) all identify themselves).

smime.p7s
Description: S/MIME Cryptographic Signature