Issues in Parsing HTTP Request "Host" Header

[TUO-Wu]

Hello, I may find some bugs with the Host header where gunicorn 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, gunicorn 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.7 80
HTTP/1.1 200 OK
Server: gunicorn
Date: Wed, 19 Mar 2025 14:03:13 GMT
Connection: keep-alive
Content-type: application/json
Content-Length: 129

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

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.7 80
HTTP/1.1 200 OK
Server: gunicorn
Date: Wed, 19 Mar 2025 15:17:09 GMT
Connection: keep-alive
Content-type: application/json
Content-Length: 113

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

[pajod]

I would like to reject dupes without backwards-incompatibly enforcing the requirement of providing a header at all.

(Thanks for the refreshingly well-written report!)

But without publicly going into much detail about the more worrying side-effects, a spot-fix won't be enough and we will probably want to increase compatibility with other WSGI software rather than decrease it. (Highly recommend the HTTP garden as a reference and testing tool for HTTP parser bugs.) At the moment I see the aiohttp, waitress, twisted, tornado tickets, but no discussion for h11.

(@kenballus Care to also share your assessment on load balancers getting confused by excessive 1xx reponses to answer the question of whether duplicate Expect: 100-continue processing also needs reconsideration?)

[kenballus]

(@kenballus Care to also share your assessment on load balancers getting confused by excessive 1xx reponses to answer the question of whether duplicate Expect: 100-continue processing also needs reconsideration?)

I'm not really sure. The HTTP Garden is a tool for testing request parsing, and right now doesn't provide any nice ways for testing response parsing.

If you're interested in collaborating on that feature, I'd welcome it :)

Thanks!

[kgaughan]

@TUO-Wu Please don't do this kind of thing in future. You've just spammed a whole bunch of repos with bug reports for no good reason. These are projects that are not meant to be directly exposed to the internet but to be served from behind a reverse proxy and all of your issues are very much "that's technically correct, which is the best kind of correct", but in no way useful. There is something to be said for defence in depth, but for anything that's going to behind a reverse proxy, you really need to pair that up with an actual PR that fixes the issue, otherwise it's just noise.

[kenballus]

@kgaughan, I encourage you to look at some of the parsing bugs that have been found to be exploitable in the past. Often, it's stuff that seems harmless in isolation, and only turns out to be dangerous because of other seemingly harmless bug in some load balancer.

Obviously, submitting PRs is better than just submitting issues, but I don't see how it's harmful to submit issues like this. It's a real (if minor) issue, and it only takes a second to close it if the maintainers don't care.

If you claim to implement a spec (like RFC 9110/9112), it's probably worth at least documenting the ways in which you knowingly deviate from it, so users can take this into account.