- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Tue, 12 Feb 2008 21:09:06 +0100
- 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 UTC