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

Re: XHR tests

From: Hallvord R. M. Steen <hallvord@opera.com>
Date: Tue, 12 Feb 2008 21:09:06 +0100
Message-ID: <1202846946.47b1fce29117d@sam.opera.com>
To: Alexey Proskuryakov <ap@webkit.org>
Cc: "Web API WG (public)" <public-webapi@w3.org>

Quoting Alexey Proskuryakov <ap@webkit.org>:

> >> The failure looks like a bug in the test script: HTTP headers are  
> >> case-insensitive, but it only allows "x-custom-header", not "X- 
> >> Custom-Header".

> > I'm not so sure. Given the
> >
> > setRequestHeader('x-custom-header', 'foo');
> >
> > do we want to allow browsers to camelcase the header name whenever  
> > it pleases them? Since some do and some don't this would be an  
> > obvious source of compatibility issues. The spec doesn't say  
> > anything but maybe we should choose one or the other and update the  
> > spec?

>    I do not see how it is something the XHR spec can change - it's  
> obviously an RFC 2616 domain, and RFC 2616 is very explicit in what it  
> says about header name case insensitivity.

Pardon, perhaps because I have not done much spec development I don't understand
the logic of that statement.

Since RFC 2616 says header names are case insensitive, it follows that
'X-Custom-Header' and 'x-custom-header' are both valid by RFC 2616, and both
are the same header. So how would we contradict 2616 by telling implementors
not to change the case of script authors' input?

What would contradict 2616 is to send different headers where names only differ
in case, as in such a request:

GET /
X-Custom-Header: foo
X-custom-header: bar

and my suggested spec change takes this into account by making name comparisons
more explicitly case-insensitive.


> > I'd consider Safari's current behaviour a nasty gotcha for developers,
> 
>   We may or may not change the behavior to be compatible with other  
> engines in this regard in the future. However, I am pretty sure that  
> an official W3C test suite should not flag us with a "FAILURE" as long  
> as we conform to the letter of RFC 2616.

I think this issue is internal in the XHR API's treatment of input strings, and
I also believe that incompatibilities between implementation should be resolved
by the spec and flagged by the tests.

-- 
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
Received on Tuesday, 12 February 2008 20:09:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 12 February 2008 20:09:22 GMT