W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: ISSUE-75: Is method case-sensitive?

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 22 Apr 2006 17:00:01 -0700
Message-Id: <4480CD59-22A0-44BD-BE11-6A691A8C11B9@apple.com>
Cc: Anne van Kesteren <annevk@opera.com>, "Web APIs WG (public)" <public-webapi@w3.org>
To: Mark Nottingham <mnot@yahoo-inc.com>

On Apr 21, 2006, at 12:53 PM, Mark Nottingham wrote:

> On 2006/04/21, at 11:13 AM, Anne van Kesteren wrote:
>>> There's a place for making sure you have a path from the current  
>>> implementations to the new standard, but this isn't it.  
>>> Specifying this behaviour well isn't going to cost anything; some  
>>> implementations won't be conformant for a little while, but  
>>> fixing them won't break any existing applications.
>> Actually, that's not true. prototype.js for example does it wrong  
>> and so do several other libraries http://annevankesteren.nl/ 
>> 2006/04/http-method#comment-5263 apparently.
> Ah, that changes things, then.
> How about
>   1) always uppercase anything matching (case-insensitive) GET POST  
>   2) everything else gets sent as-is
> (this was one of the options already mentioned, no?)

This sounds viable but also harder to implement than always  
uppercasing and the benefits seem purely hypothetical.

BTW I don't understand why people think losing the ability to send  
lowercase or mixed-cased methods (something that is highly unlikely  
to have interesting use cases) amounts to the sin of "profiling  
http", but no one objected to restricting what headers may be sent,  
even though that "profiles http" just as much, and in a way that has  
more practical consequences.

Let's face it, XMLHttpRequest only offers access to a subset of HTTP  
protocol features, this is not avoidable, now let's pick that subset  
based on pragmatic considerations, not theoretical purity.

Received on Sunday, 23 April 2006 00:00:31 UTC

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