Method case sensitivity

[mnot]

HTTP defines methods as case-insensitive, but many implementations / apps built on HTTP case-normalise to uppercase.

I don't remember discussing this on the list, and a quick search of the issues list doesn't show anything.

See also w3c/ServiceWorker#120.

[reschke]

What application except browsers are known to do this?

EDIT: as far as I can tell, browser do not case-normalize in XHR. So what is this issue about? Did they start doing so with FETCH?

[mnot]

https://fetch.spec.whatwg.org/#methods --

To normalize a method, if it is a byte-case-insensitive match for DELETE, GET, HEAD, OPTIONS, POST, or PUT, byte-uppercase it.

So they have limited case-insensitivity for certain methods.

IIRC I have seen this commonly in browsers, but I don't see a test in WPT (@annevk?). Julian, your test doesn't cover it either.

Given that the Fetch requirement effectively means that these methods are only ever uppercase on the wire, I don't think we have an interop problem; the only issue is that someone who (very foolishly, IMO) uses a case variant of one of these methods is going to be disappointed.

Could of things we could do here (not exclusive):

1. Tell IANA not to register methods that only vary in case from existing ones
2. Advise / require clients to case-normalise these (and only these) methods
3. Restrict methods to uppercase

[royfielding]

I don’t believe this is relevant to the protocol requirements, nor does it suggest any limitations on IANA defined methods. It is just a workaround due to some bad history with HTML form definitions. The methods are already defined as case sensitive. How they get from user authoring/input/configuration to a choice of method is governed by the language/dialog/file definition, not by HTTP. If someone sends a method with the wrong case, we have a status code for that. ....Roy

…

On Mar 24, 2018, at 12:12 PM, Mark Nottingham ***@***.***> wrote: https://fetch.spec.whatwg.org/#methods -- To normalize a method, if it is a byte-case-insensitive match for DELETE, GET, HEAD, OPTIONS, POST, or PUT, byte-uppercase it. So they have limited case-insensitivity for certain methods. IIRC I have seen this commonly in browsers, but I don't see a test in WPT ***@***.***?). Julian, your test doesn't cover it either. Given that the Fetch requirement effectively means that these methods are only ever uppercase on the wire, I don't think we have an interop problem; the only issue is that someone who (very foolishly, IMO) uses a case variant of one of these methods is going to be disappointed. Could of things we could do here (not exclusive): Tell IANA not to register methods that only vary in case from existing ones Advise / require clients to case-normalise these (and only these) methods Restrict methods to uppercase — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[annevk]

It's not really related to HTML forms. It's just a bad client-side implementation that content came to rely on. Here's some method tests:

• http://w3c-test.org/xhr/open-method-bogus.htm
• http://w3c-test.org/xhr/open-method-case-insensitive.htm
• http://w3c-test.org/xhr/open-method-case-sensitive.htm
• http://w3c-test.org/xhr/open-method-insecure.htm

[annevk]

(I've often wondered whether we should offer a way to make get, Get, etc. requests, but I'm a little worried there might be security implications of sorts at this point and the benefit seems rather questionable. In a way it's similar to browsers not supporting a request body for GET.)

[mnot]

Given that registration requires IETF consensus, it seems pretty unlikely we'd register a method that differs in case alone, so I tend to agree we don't need to limit IANA.

Is it worthwhile to note that some implementations case-normalise some methods?

[annevk]

Given

The method token is case-sensitive because it might be used as a gateway to object-based systems with case-sensitive method names.

I think so, as get is a pretty common method name.

I also find potential for confusion in

By convention, standardized methods are defined in all-uppercase US-ASCII letters.

as it could suggest they are not case-sensitive if you do not read carefully and no such convention is stated for other syntax aspects, such as header fields, despite there clearly being one.

[reschke]

FWIW, I added a test at http://test.greenbytes.de/tech/tc/httpredirects/t301methods.html which tests "lowerCase".

[mnot]

Perhaps if we moved the "By convention..." sentence up two paragraphs, after it's explained that they are case-sensitive?

[reschke]

Works for me.

[royfielding]

+1 on moving it up.

[mnot]

Done. I haven't listed in change notes as this is just editorial; please yell if that causes discomfort.

I also broke the paragraph out, since that one was getting big, in ad9a322.