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

On Apr 23, 2006, at 02:00, Maciej Stachowiak wrote:
> On Apr 21, 2006, at 12:53 PM, Mark Nottingham wrote:
>> How about
>>   1) always uppercase anything matching (case-insensitive) GET  
>> POST PUT DELETE
>>   2) everything else gets sent as-is
>
> This sounds viable but also harder to implement than always  
> uppercasing and the benefits seem purely hypothetical.

It is a little bit more work but it doesn't really sound much harder  
to implement to me. The benefits are, I believe, three: it keeps  
existing content that works today working, it allows for other  
methods to use lowercase methods, and, last but not least, it appears  
to be the position most likely to garner consensus.

> 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.

Unless I've missed something, we have only forbidden headers that we  
know of, and that we know to be problematic, most notably for  
security reasons (there has been push-back on restricting for other  
reasons, e.g. the encoding case). If a new HTTP extension comes  
about, the people designing it will generally not have to care about  
the existence and behaviour of XHR. This is fine since it promotes  
independence of design.

If on the other hand we decide to prohibit lowercase methods,  
specifiers of such extensions will be required to have arcane  
knowledge of XHR, of the kind only possessed by people who will have  
read the spec paying great attention to detail. It's not good for  
independence, it's not good for least surprise, and while small it's  
still another addition to the many things that can trip people  
writing specifications or creating technology. If possible, it should  
thus be avoided.

> 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.

I wholeheartedly agree, but the problem is that one's theoretical  
purity is often someone else's pragmatism. We could try to figure out  
who's right, but it would likely get quite theoretical, and more  
importantly rather long :) What would folks think of closing the  
issue with Mark's proposal?

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/

Received on Sunday, 23 April 2006 01:36:11 UTC