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
