Parsing issue of the CONNECT method

[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 CONNECT requests.
RFC 9112 says this:

A server MUST reject a CONNECT request that targets an empty or invalid port number, typically by responding with a 400 (Bad Request) status code.

However, waitress does not reject such CONNECT request, and does not establish a proxy connection. It handles CONNECT requests just like GET or POST, and responses with 200 OK.
For example:

CONNECT victim.com HTTP/1.1\r\n
Host: victim.com\r\n
\r\n

$ echo -ne "CONNECT victim.com HTTP/1.1\r\nHost: victim.com\r\n\r\n" | nc 172.18.0.6 80
HTTP/1.1 200 OK
Content-Length: 129
Content-Type: application/json
Date: Thu, 20 Mar 2025 09:07:15 GMT
Server: waitress

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

[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.

[digitalresistor]

Waitress leaves it up to the WSGI application on how to handle the request. If a WSGI application wants to implement a proxy with CONNECT then it can do so. Waitress is not in the business of validating whether the request method is valid or not.