default port in http header 'host' can result in 502 bad gateway

[GlenDC]

When proxying traffic via g3proxy over a server type such as http_proxy you can end up with a host header value in the form domain:port. Strictly speaking this is fine and RFC compliant. However there are plenty of reverse proxies out there such as Nginx which do a literal mapping on the host header value to forward the traffic to the appropriate internal service. This won't be able to find a mapping in case a default port is there (E.g. 443 when using https or 80 when using http).

Meaning something like:

Host: www.example.com:443

would result in a 502 status code for such scenarios,
while:

Host: www.example.com

would work.

I can submit a PR if you want but would need some guidance on where you see the appropriate solution for this,
as there are couple of different ways I can see this being solved.

One approach is the sanitizer approach where you might sanitize headers for both h1 and h2 in locations such as lib/g3-http/src/server/request.rs and lib/g3-http/src/server/transparent.rs. For this i can probably provide a patch starting for the host header already where default ports would be stripped.

Another approach could be that you make sure it get fixed for that specific flow. For that I would need guidance and pointers.

I would personally go for the sanitizer approach but wanted to check with you.

[zh-jq]

When proxying traffic via g3proxy over a server type such as http_proxy you can end up with a host header value in the form domain:port.

g3proxy should send the same Host header value as in the client request. It's a bug if the Host header get changed.

Meaning something like:

Host: www.example.com:443

would result in a 502 status code for such scenarios, while:

Host: www.example.com

would work.

I can submit a PR if you want but would need some guidance on where you see the appropriate solution for this, as there are couple of different ways I can see this being solved.

One approach is the sanitizer approach where you might sanitize headers for both h1 and h2 in locations such as lib/g3-http/src/server/request.rs and lib/g3-http/src/server/transparent.rs. For this i can probably provide a patch starting for the host header already where default ports would be stripped.

All end-to-end headers should be kept the same as in the client when possible.

Another approach could be that you make sure it get fixed for that specific flow. For that I would need guidance and pointers.

You can show the bad cases so we can decide how to fix it.

[GlenDC]

Again RFC wise you are correct, but reality is not a collection of RFC's.

The fact is the traffic is changed due to it going via the proxy (G3proxy) in the first place.
As web clients won't put that 443 port as part of the host header if it wasn't for the fact that
it was going over a proxy.

I cannot give any examples at the moment from open sources. But you should easily be able to trigger it yourself
by setting up one of many reverse proxies such as Nginx and see it fail because it doesn't know what to do with your domain:443 example as that is not how that reverse proxy is configured.

[zh-jq]

The fact is the traffic is changed due to it going via the proxy (G3proxy) in the first place. As web clients won't put that 443 port as part of the host header if it wasn't for the fact that it was going over a proxy.

This will be a bug if g3proxy added the port. And I can't reproduce this by using the g3proxy/examples/simple-httpproxy config.

[GlenDC]

Nope g3proxy didn't add the port, it's the client.

[zh-jq]

Nope g3proxy didn't add the port, it's the client.

It's OK to delete the port part in lib/g3-http/src/server/request.rs and lib/g3-http/src/server/transparent.rs when parsing the Host header, but this should be configurable and disabled by default.