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

Re: [XMLHttpRequest] LC-20080415 comment

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>
Message-ID: <a2cfc6264f01d90f39e61780b044fc71c46f621a@localhost>

"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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 12 May 2008 15:49:27 GMT