W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Accept header setting in XHR

From: Peter Michaux <petermichaux@gmail.com>
Date: Tue, 25 Aug 2009 10:06:27 -0700
Message-ID: <3cbaf1c80908251006l26a18bd0l729a4171c7e334ef@mail.gmail.com>
To: public-webapps@w3.org
I am looking at the current Working Draft of the XHR spec at the end
of section 4.6.3


"Unless set through setRequestHeader() user agents should set the
Accept and Accept-Language headers as well."

This doesn't specify what the user agent should/must do in the case
where the Accept header is set through setRequestHeader(). In my
opinion something like the following would be better.

"If Accept is set through setRequestHeader(), user agents must not
set, append or otherwise modify the Accept header. If the Accept
header is not set thorugh setRequestHeader(), user agents should set
the Accept header. Same for the Accept-Language header."

I think avoiding the word "Unless" would also be an improvement as it
is clearer to just use "If".


The reason this comes up is I want to specify that "application/json"
is the only acceptable format. Internet Explorer 6+, Firefox 3, Safari
3+ and Chrome allow me to do this. Opera 9.64 appends other formats to
the Accept header when they are not at all acceptable for my XHR
request. Opera's behavior does not go against the current spec,
however, because this situation is not specified.

Example code:

var xhr = makeXhr();
xhr.onreadystatechange = function() {};
xhr.open('GET', '/', true);
xhr.setRequestHeader('Accept', 'application/json');

IE6-8, FF3, S3-4, C1 send
Accept: application/json

Opera 9.64 sends
Accept: application/json, text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1

Although the Opera behavior is not against the spec, the behavior has
made the Accept header unusable in my situation. Without question, an
image response is certainly is not acceptable when I'm requesting some
text data in JSON format.

Received on Tuesday, 25 August 2009 17:18:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC