🐛 Bug Report — Request Throws 'Invalid HTTP method' Error when Using Lowercase Method "patch"

[Kynson]

The Issue

new Request('', {method: 'patch'}) unexpectedly throws error 'Invalid HTTP method string: patch' but new Request('', {method: 'PATCH'}) works fine.

Minimal Reproducible Example: Workers Playground

Expected Behaviour

Both lowercase and uppercase method string should be supported (other methods support both lowercase and uppercase).

Suspected Cause

L1000 of workerd/api/http.c++:

switch(method) {
                case kj::HttpMethod::GET:
                case kj::HttpMethod::POST:
                case kj::HttpMethod::PUT:
                case kj::HttpMethod::DELETE:
                case kj::HttpMethod::HEAD:
                case kj::HttpMethod::OPTIONS:
                  break;
                default:
                  JSG_FAIL_REQUIRE(TypeError, kj::str("Invalid HTTP method string: ", originalMethod));
}

Presumably, the switch statement will run when a lowercase method string is passed to the constructor as tryParseHttpMethod failed to parse the lowercase method string. Yet, PATCH is missing from the switch statement, so the error is thrown. I am not particularly familiar with C++ so I might be wrong with this.

[kentonv]

@harrishancock I don't suppose you remember why we're only case-insensitive for those six method names? Was this in the spec or something?

[jasnell]

If by spec you mean the http spec, there's nothing about special handling casing of only these basic 6 methods. Per the spec, all http methods are case sensitive.

https://www.rfc-editor.org/rfc/rfc7231#section-4

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

So we really ought to be treating get, post, put, delete, head, and options as invalid also.

For the original ask here, PATCH is correct. patch is incorrect.

[jasnell]

Testing chromium, it does appear that chromium's implementation will automatically convert get to GET but won't convert patch to PATCH... and yeah, this appears to be part of the fetch standard https://fetch.spec.whatwg.org/#methods

It even calls out patch vs PATCH explicitly.

So it would appear that our implemented behavior is correct per the fetch spec and accordingly bends a rule of the HTTP RFC to special case these six methods. Good fun.

Quick test across run times for console.log((new Request('http://example.org', { method: 'patch' }).method)

• Chromium browsers: patch (per the spec, not uppercased)
• Node.js: patch (per the spec, not uppercased)
• Deno: PATCH (does not match spec, uppercased)
• Bun: PATCH (does not match spec, uppercased)

[kentonv]

I guess we're still violating spec either way in that if you specify patch lower-case, we throw an exception, whereas we should accept it. It seems better to uppercase it than to throw an exception I think.

Arguably we should actually expand the underlying KJ HTTP implementation to support arbitrary method names, rather than restricting them to an enum. I'm not excited about doing that, though, as:

• We've literally never heard anyone complain about wanting to use a method that's not on our list.
• There's some risk of security (request smuggling) bugs if someone defines a new method which, like CONNECT, doesn't use standard HTTP message framing.

So I'd be in favor of just upper-casing all methods.

[jasnell]

We've literally never heard anyone complain about wanting to use a method that's not on our list.

To be fair, they probably wouldn't. If they needed a method that didn't work in workers they're more likely to just not use workers than to complain about it not working

That said, upper-casing all methods is fine as a first step, I think. Likely requires a compat flag tho.

[jasnell]

Marking as a feature request rather than a bug.

[jasnell]

This was closed automatically because the fix has been landed. The actual change will not go out to production for another week. Note that the change will become the default behavior for new workers deployed on-or-after Nov 14th (as currently planned). Workers using a compat date prior to that will need to opt in with a compatibility flag.