- 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>
On Tue, 12 Feb 2008 21:24:35 +0100, Julian Reschke <julian.reschke@gmx.de> 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
Received on Wednesday, 13 February 2008 14:18:18 UTC