Re: setRequestHeader underspecified - setting "Accept" header as an example

On Tue, 18 Nov 2008 13:50:36 +0100, Hallvord R. M. Steen  
<hallvord@opera.com> wrote:
> I've found a site that requires that any UA default value is overridden  
> with the new value when using setRequestHeader('Accept', ..).
>
> (For reference: the site is mail.163.com, it uses XHR extensively to  
> fetch data and sets Accept header to "text/javascript" to fetch JSON  
> content. If that value is appended to the UA's internal list instead of  
> replacing it the server returns XML instead of JSON, which doesn't go  
> down well with the JSON "parsing" - i.e. eval() - they put the data  
> through.)
>
> The spec says about "setRequestHeader()":
>
>> If the header argument is in the list of request headers either use  
>> multiple headers, combine the values or use a combination of those  
>> (section 4.2, RFC 2616).
>
> I think this needs to be way more specific. We probably need to verify  
> what existing UAs do for actual header values, and make some sensible  
> rules from that.

It also says that UAs should have an Accept header of */* when they supply  
one. Does the server still give XML back in that scenario?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>