- From: Stewart Brodie <stewart.brodie@antplc.com>
- Date: Mon, 12 May 2008 16:48:48 +0100
- To: "Anne van Kesteren" <annevk@opera.com>
- Cc: "Web API WG (public)" <public-webapi@w3.org>
"Anne van Kesteren" <annevk@opera.com> wrote: > On Wed, 16 Apr 2008 13:08:37 +0200, Stewart Brodie > <stewart.brodie@antplc.com> wrote: > > In the last paragraph on send(data) (i.e. just above the start of the bit > > about the abort() method), there is a statement (which is missing the > > word "header" at the end, but that's not the point I wish to raise) : > > > > "it MUST NOT automatically set the Accept." > > > > I think that this is a bad idea, because some servers fail to deliver > > resources in the absence of the Accept header where the resource has > > multiple variants available. Some older versions of IIS are known to > > fail in this manner. There may be others that I'm not aware of too, > > obviously. > > I see. What you're stating seems also in line with browser behavior so I > have changed this to make Accept handling identical to that of > Accept-Language. Unless it is specified through setRequestHeader() the > user agent should provide it. > > http://dev.w3.org/2006/webapi/XMLHttpRequest/ Thanks. > I have not followed your request of requiring a particular value as that > does not seem in line with implementations and seems needlessly > restrictive. I hope that's ok. I'm guessing that you mean that they add their own default Accept header? If so, then I think those implementations are buggy. However, given that implementations vary in this respect already, then it'll have to be OK. The only reason I suggested forcing implementations to use "*/*" as the value for an automatically added header is that it preserves the semantics of the request, since this is the default to be assumed by HTTP servers in the absence of the header (RFC2396, section 14.1). Should clients be warned that failing to set an Accept header explicitly will lead to inconsistent behaviour between different UAs? By using values other than "*/*", the UA is overriding the script's type preference, as it restricts the types that the server may return - behaviour which I would class as a bug. The UA isn't going to be processing the returned entity body - the script is. I realise that the whole problem is caused by the new SHOULD requirement in the first place, but, unfortunately, it is needed for web compatibility. -- Stewart Brodie Software Engineer ANT Software Limited
Received on Monday, 12 May 2008 15:49:27 UTC