Issues in Parsing HTTP Request "Host" Header

[TUO-Wu]

Hello, I may find some bugs with the Host header where tornado parses HTTP requests.
RFC 9112 says this:

A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than one Host header field line or a Host header field with an invalid field value.

This should imply that the HTTP server must reject requests with redundant Host headers or requests with missing Host headers. But in both cases, tornado did not reject.

Examples:

POST / HTTP/1.1\r\n
Host: victim1.com\r\n
Host: victim2.com\r\n
\r\n

$ echo -ne "POST / HTTP/1.1\r\nHost: victim1.com\r\nHost: victim2.com\r\n\r\n" | nc 172.18.0.5 80
HTTP/1.1 200 OK
Server: TornadoServer/6.5.dev1
Content-Type: text/html; charset=UTF-8
Date: Wed, 19 Mar 2025 15:32:17 GMT
Content-Length: 145

{"headers":[["SG9zdA==","dmljdGltMS5jb20="],["SG9zdA==","dmljdGltMi5jb20="]],"body":"","method":"UE9TVA==","uri":"Lw==","version":"SFRUUC8xLjE="}

or

POST / HTTP/1.1\r\n
Content-Length: 0\r\n
\r\n

$ echo -ne "POST / HTTP/1.1\r\nContent-Length: 0\r\n\r\n" | nc 172.18.0.5 80
HTTP/1.1 200 OK
Server: TornadoServer/6.5.dev1
Content-Type: text/html; charset=UTF-8
Date: Wed, 19 Mar 2025 15:32:40 GMT
Content-Length: 113

{"headers":[["Q29udGVudC1MZW5ndGg=","MA=="]],"body":"","method":"UE9TVA==","uri":"Lw==","version":"SFRUUC8xLjE="}

The version I tested was f62afc3.

[bdarnell]

Ack that we should be rejecting multiple Host headers. I'm not sure about rejecting requests with no host header - we support those for HTTP/1.0 compatibility (does that matter any more? I suppose It's simpler for the rare occasions when you type in a request by hand over telnet or something).

Maybe we should reject host headers containing commas too (which may indicate multiple header lines that were combined according to RFC 9110 section 5.2 and 5.3)? The host header is defined as uri-host which is very permissive to support different URI schemes, but for HTTP this can probably be narrowed down to DNS-legal names.

Part of the problem is that we don't require you to specify expected hostnames (hostname matching rules default to .*) and even when you specify it it's common to use unescaped . to match too much.