Incorrect Handling of Absolute-Form Request-Target Authority

[TUO-Wu]

Version
fc592e8

Platform
Ubuntu 11.4.0-1ubuntu1~22.04

Description
Hello, I may have found a bug in waitress's parsing of absolute-form request-target authority.
RFC 9112 says this:

When an origin server receives a request with an absolute-form of request-target, the origin server MUST ignore the received Host header field (if any) and instead use the host information of the request-target.

However, I noticed that when an HTTP request is sent with an absolute-form request-target where the authority differs from the Host header, waitress appears to prioritize the Host header over the request-target’s authority.
For example:

GET http://evil.com/page HTTP/1.1\r\n
Host: victim.com\r\n
\r\n

Waitress's response:

$ echo -ne "GET http://evil.com/page HTTP/1.1\r\nHost: victim.com\r\n\r\n" | nc 172.18.0.6 80
HTTP/1.1 200 OK
Content-Length: 113
Content-Type: application/json
Date: Wed, 26 Mar 2025 14:53:24 GMT
Server: waitress

{"headers":[["SE9TVA==","dmljdGltLmNvbQ=="]],"body":"","version":"SFRUUC8xLjE=","uri":"L3BhZ2U=","method":"R0VU"}

From the response body, specifically the URI, it appears that waitress parses the above request as:

GET /page HTTP/1.1\r\n
Host: victim.com\r\n
\r\n

This shows that waitress did not ignore the received Host header field, which may be a violation of the protocol specifications.

[kgaughan]

I'm not going to close this out straight away, but you do need to keep in mind that Waitress is not intended to be exposed to the internet. It's intended to be either (a) used for development or (b) used behind a reverse proxy that provides TLS termination and to also deal with said nuances of HTTP. In other words, the HTTPS headers ought to be normalised before Waitress even sees them. Can you construct an attack where the likes of Apache, Nginx, or Caddy are in front of Waitress.