W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

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

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Fri, 16 May 2008 11:40:08 +0200
Message-ID: <482D5678.9050305@students.cs.uu.nl>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Anne van Kesteren <annevk@opera.com>, "Web API WG (public)" <public-webapi@w3.org>
Julian Reschke schreef:
> Anne van Kesteren wrote:
>> On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst 
>> <lholst@students.cs.uu.nl> 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
>>> acceptable */*), but it would be better to leave it out entirely. 
>>> Also see:
>>> http://www.grauw.nl/blog/entry/470
>> 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. 

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).


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.

Received on Friday, 16 May 2008 09:52:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC