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

On Apr 22, 2006, at 6:36 PM, Robin Berjon wrote:

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

I don't think there is any showstopper technical flaw with Mark's  
proposal, and I almost proposed something similar myself.

However, doing case-insensitive compare against a list before  
deciding whether to uppercase does add some implementation complexity  
and more opportunity for bugs. Even if the implementation complexity  
for any given design is small, we should not just increase complexity  
gratuitously. Instead we should be sure it is justified with a real  
and significant use case.

So far no one has named a server on the publicly accessible web where  
sending a method in arbitrary case is required, or any current or  
expected future standard that uses anything but all-uppercase http  
method names.

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

Actually, they probably will have to consider XHR; if they add any  
headers that can cause security problems when set from untrusted web  
content, then their spec will have a security problem. Protocol specs  
need to consider use cases.

But really, the point is not what we restricted or why. The bottom  
line is, we've already crossed the "profiling http" bridge.

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

Seems to be that so far, all such spec authors have successfully made  
their method names all uppercase without having an XHR spec to look  
at. So this problem seems more theoretical than real.

>> 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 :)

No, I don't accept that. You can demonstrate that something is a  
pragmatic issue by showing a real-world example. You can't handwave  
away the difference.

In this case, an example of a spec using non-uppercase http method  
names, or of a server requiring such, would demonstrate the need for  
the feature. Anne demonstrated the need to uppercase 'get' and 'post'  
by showing widely deployed JS libraries depending on this behavior.  
So far no one has has made a similar demonstration of the benefits of  
not uppercasing 'foobar'. I welcome such research and would gladly  
change my tune based on the results.

That being said, whether all methods are uppercased or only the  
methods that get significant use, is not really a major issue. But  
let's not just casually increase spec complexity without doing our  
due diligence.

Regards,
Maciej

Received on Sunday, 23 April 2006 03:18:49 UTC