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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Laurens Holst-2
The current CVS version says that:

    “Unless set through |setRequestHeader()
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/webapi/XMLHttpRequest/Overview.html?rev=1.176&content-type=text/html;%20charset=iso-8859-1#setrequestheader>|

user agents /should/ set the |Accept| and |Accept-Language| headers as
well.”

This was originally

    “it /must not/ automatically set the |Accept|.”

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


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

lholst.vcf (196 bytes) Download Attachment
smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Anne van Kesteren-2

On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst  
<[hidden email]> 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?


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

Reply | Threaded
Open this post in threaded view
|

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

Laurens Holst-2
Anne van Kesteren schreef:

> On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst
> <[hidden email]> 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?
It would not be my preferred resolution, I like the old text better (and
if possible would like to see an example of a website that breaks). But
it would be acceptable.

I assume this is the thread you are talking about:

http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0133.html
http://lists.w3.org/Archives/Public/public-webapi/2008May/0137.html

Thanks for your response.

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


lholst.vcf (196 bytes) Download Attachment
smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Anne van Kesteren-2

Anne van Kesteren wrote:

>
> On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst
> <[hidden email]> 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.

BR, Julian


Reply | Threaded
Open this post in threaded view
|

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

Laurens Holst-2
Julian Reschke schreef:

> Anne van Kesteren wrote:
>>
>> On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst
>> <[hidden email]> 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).

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


lholst.vcf (196 bytes) Download Attachment
smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Anne van Kesteren-2
In reply to this post by Laurens Holst-2

On Fri, 16 May 2008 11:28:43 +0200, Laurens Holst  
<[hidden email]> wrote:
> It would not be my preferred resolution, I like the old text better (and
> if possible would like to see an example of a website that breaks). But
> it would be acceptable.

Ok, fixed. Thanks!


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

Reply | Threaded
Open this post in threaded view
|

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

Jonas Sicking-2
In reply to this post by Julian Reschke

Julian Reschke wrote:

>
> Anne van Kesteren wrote:
>>
>> On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst
>> <[hidden email]> 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.

If "*/*" is semantically the same as not sending the header at all, and
the former works with more servers, I would prefer that we use the former.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke

Jonas Sicking wrote:
> ...
> If "*/*" is semantically the same as not sending the header at all, and
> the former works with more servers, I would prefer that we use the former.
> ...

I would prefer not to silently change what the client requested.

If a server can't cope with it (evidence, please!), fix it.

BR, Julian


Reply | Threaded
Open this post in threaded view
|

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

Stewart Brodie

Julian Reschke <[hidden email]> wrote:

>
> Jonas Sicking wrote:
> > ...
> > If "*/*" is semantically the same as not sending the header at all, and
> > the former works with more servers, I would prefer that we use the
former.
> > ...
>
> I would prefer not to silently change what the client requested.

It's semantically equivalent - it does not change the request, in the same
way that adding the Connection header does not change the request.  It's not
like we're requiring that the UA add something that changes the meaning
(even though that's what some of the desktop browser vendors seem to be
doing anyway!)


> If a server can't cope with it (evidence, please!), fix it.

Some older versions of Microsoft IIS are the servers that I've come across
that fail to cope with it.  It is unrealistic to expect these to be
undeployed any time soon.  The comment in my code does not specify version
numbers - it simply indicates that a lack of an Accept header causes some
versions of IIS to return a None Match error.  On that basis, and because
sending "Accept: */*" fixes the problem, I am assuming that the fault lies
in the content negotation code.


--
Stewart Brodie
Software Engineer
ANT Software Limited

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke

Stewart Brodie wrote:
>> If a server can't cope with it (evidence, please!), fix it.
>
> Some older versions of Microsoft IIS are the servers that I've come across
> that fail to cope with it.  It is unrealistic to expect these to be
> undeployed any time soon.  The comment in my code does not specify version
> numbers - it simply indicates that a lack of an Accept header causes some
> versions of IIS to return a None Match error.  On that basis, and because
> sending "Accept: */*" fixes the problem, I am assuming that the fault lies
> in the content negotation code.

Well, the client alway can set "Accept" to "*/*" if it needs to
communicate with that server.

Please do not burden the spec with workarounds when it is clearly *not*
required.

BR, Julian

Reply | Threaded
Open this post in threaded view
|

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

Stewart Brodie

Julian Reschke <[hidden email]> wrote:

> Stewart Brodie wrote:
> >> If a server can't cope with it (evidence, please!), fix it.
> >
> > Some older versions of Microsoft IIS are the servers that I've come
> > across that fail to cope with it.  It is unrealistic to expect these to
> > be undeployed any time soon.  The comment in my code does not specify
> > version numbers - it simply indicates that a lack of an Accept header
> > causes some versions of IIS to return a None Match error.  On that
> > basis, and because sending "Accept: */*" fixes the problem, I am
> > assuming that the fault lies in the content negotation code.
>
> Well, the client alway can set "Accept" to "*/*" if it needs to
> communicate with that server.

That was my original point: the XHR LC explicitly prohibited the UA from
adding an Accept header.  That's why I requested that it be changed from a
MUST NOT requirement.  As far as I'm concerned, the UA has to be free to
implement such workarounds, especially any that are semantically
transparent.


> Please do not burden the spec with workarounds when it is clearly *not*
> required.

I don't think it is being specified.  My original suggestion was to add
something saying that if the client chose to add the header then it SHOULD
use "*/*" as the value.  Anne already rejected this on the grounds that
existing desktop browsers send arbitrary values for the header.  I don't
like that situation (I think those browsers are simply broken), but given
that the desktop browsers aren't going to change to comply, accepted that it
could be left unspecified.


--
Stewart Brodie
Software Engineer
ANT Software Limited

Reply | Threaded
Open this post in threaded view
|

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

Anne van Kesteren-2

On Mon, 19 May 2008 12:47:23 +0200, Stewart Brodie  
<[hidden email]> wrote:
> I don't think it is being specified.  My original suggestion was to add
> something saying that if the client chose to add the header then it  
> SHOULD
> use "*/*" as the value.  Anne already rejected this on the grounds that
> existing desktop browsers send arbitrary values for the header.  I don't
> like that situation (I think those browsers are simply broken), but given
> that the desktop browsers aren't going to change to comply, accepted  
> that it could be left unspecified.

I changed this later on and made it do what you requested, by the way.


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