- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 22 Apr 2006 17:00:01 -0700
- To: Mark Nottingham <mnot@yahoo-inc.com>
- Cc: Anne van Kesteren <annevk@opera.com>, "Web APIs WG (public)" <public-webapi@w3.org>
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 > PUT DELETE > 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. Regards, Maciej
Received on Sunday, 23 April 2006 00:00:31 UTC