Julian Reschke schreef:
Sorry, was reading one thing, but thinking about something else.

Thinking of it, could you please add a clarification that setting to an empty string is legal, and MUST NOT be ignored? I recall that Microsoft's original XHR (ActiveX) implementation got that wrong, not setting the header at all.

When invoking request.setRequestHeader('Accept', ''):

- Firefox 3b5 removes the Accept header
- Internet Explorer 8 (in IE7 mode) sends Accept: */*
- Safari 3.1.1 sends Accept:
- Opera 9.24 sends Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1

When invoking request.setRequestHeader('Accept', null):

- Firefox 3b5 removes the Accept header
- Internet Explorer 8 (in IE7 mode) sends Accept: null
- Safari 3.1.1 sends Accept: null
- Opera 9.24 sends Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1

So it is clear that here, too, browsers are in great disagreement. I am not sure what the correct approach here is, though '' meaning setting “Accept” and null meaning removal of the header sounds sensible.

Note by the way that Opera always prepends the set Accept header to its default value, resulting in e.g. Accept: */*, text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 when invoking request.setRequestHeader('Accept', null);

I can’t believe how horribly broken this all is. No wonder few people depend on this header. Fortunately, as a result it can also be fixed without breaking much.

I’ve also posted these results at http://www.grauw.nl/blog/entry/470 , the page source contains a test case.


~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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to