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

Re: XHR tests

From: Hallvord R. M. Steen <hallvord@opera.com>
Date: Wed, 13 Feb 2008 15:19:02 +0100
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Alexey Proskuryakov" <ap@webkit.org>, "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.t6gvd0q7a3v5gv@hr-opera.oslo.opera.com>

On Tue, 12 Feb 2008 21:24:35 +0100, Julian Reschke <julian.reschke@gmx.de>  

>> 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?
> The XHR implementation may sit on top of an HTTP stack that normalizes  
> header names, for instance to camelCase.

Thanks, I'm enlightened - also thanks to Alexey for his half of the  
explanation ;)
I've fixed the test, and Safari now passes. Maybe the spec should add a  
non-normative note or two, to implementors that this is a gotcha and they  
may run into scripts that expect case to be preserved, and to authors that  
they really should ensure case-insensitive comparisons in their backend  

Also fixed another test suite backend script with the same problem. Don't  
know off the top of my head what tests use it, but they will presumably  
also change from failed to passed in Safari :-) .

Related issue: as far as I can see the spec doesn't say anything about  

setRequestHeader( 'x-test', .. )
setRequestHeader( 'X-Test', .. )

either. Should it say explicitly that when considering whether a header  
already exists, matching needs to be case-insensitive? Here's a test:
Firefox 2 fails, the rest of the usual suspects pass.

Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
Opera - simply the best Internet experience
Received on Wednesday, 13 February 2008 14:18:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:25 UTC