Re: XHR LC comment: Accept header went from MUST NOT to SHOULD
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
Re: XHR LC comment: Accept header went from MUST NOT to SHOULD
Julian Reschke [EMAIL PROTECTED] 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
Re: XHR LC comment: Accept header went from MUST NOT to SHOULD
Julian Reschke [EMAIL PROTECTED] 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
Re: XHR LC comment: Accept header went from MUST NOT to SHOULD
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
Re: XHR LC comment: Accept header went from MUST NOT to SHOULD
Julian Reschke schreef: Anne van Kesteren wrote: On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst [EMAIL PROTECTED] 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. begin:vcard fn:Laurens Holst n:Holst;Laurens email;internet:[EMAIL PROTECTED] tel;cell:(+31) 06-41765048 version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: XHR LC comment: Accept header went from MUST NOT to SHOULD
Anne van Kesteren wrote: On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst [EMAIL PROTECTED] 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
