Respond 400 to malformed methods instead of 405#3338
Respond 400 to malformed methods instead of 405#3338kenballus wants to merge 4 commits intotornadoweb:masterfrom kenballus:master
Conversation
|
This makes sense, but does it ever matter in practice? It doesn't seem worth the (small) performance cost of an extra re.match call. However, I think we could merge the split and version re.match into one big regex to parse the request line and probably improve performance while being more strict about method naming. |
|
The issue is that 405 is cacheable. When Tornado is deployed behind a cache server that parses methods differently from the way that Tornado does, there's the potential for cache poisoning. For example, there exist caches that forward Of course, that behavior is a bug in the cache, and needs to be fixed there too. |
|
Ah, I see. RFC 9110 section 9.1 also distinguishes between methods that are not recognized (501) and those that are recognized but not supported by the target resource (405). The logic behind that is probably similar. |
The method is now restricted to being valid token characters as defined in RFC 9110, allowing us to correctly issue status code 400 or 405 as appropriate (this can make a difference with some caching proxies). The request-target no longer allows control characters. This is less strict than the RFC (which does not allow non-ascii characters), but prioritizes backwards compatibility. Fixes tornadoweb#3415 Closes tornadoweb#3338
|
I have a regex-based version of this in #3473 |
2 participants
The HTTP standard has a grammar rule that defines valid HTTP methods. This patch checks that methods conform to that rule. Note that this does not preclude a user from defining their own custom methods; only that such custom methods cannot contain (e.g.) null bytes and other crazy junk like that.