On Tue, 12 Feb 2008 21:24:35 +0100, Julian Reschke <[EMAIL PROTECTED]>
wrote:
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
code.
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
handling
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:
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/044.htm
Firefox 2 fails, the rest of the usual suspects pass.
--
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience
