reverseproxy: Fix check for header_up Host {upstream_hostport} redundancy

[yubiuser]

PR #7454 changed the header from header_up Host {hostport} to header_up Host {upstream_hostport} when reverse_proxy for HTTPS.

However, the PR forgot to change a parser check to the new default. This results in logspam when users revert to the old behavior setting header_up Host {hostport}. Caddy starts to warn about unnecessary header_up being doubled - while this is not true anymore.

No AI was used.

[CLAassistant]

All committers have signed the CLA.

[francislavoie]

The change is not quite right, it needs to take into account that hostport is only passed for HTTPS and not HTTP.

[yubiuser]

Thanks, you're correct. I've added a commit that checks if the commonScheme is https and only in this case performs the check.

[mholt]

This LGTM. Any other changes needed @francislavoie ?

[francislavoie]

It's technically not whether the scheme is https but rather if TLS is enabled on the transport which can happen due to a few different transport options.

[mholt]

Ok yeah that's a good point. @yubiuser how would you feel about changing that?

[yubiuser]

I'll look into it, but I'm not familiar with the code base so I might miss some of the possible transport options to enable TLS.

[francislavoie]

Basically the logic would need to be moved around line 884 where (after the big switch) when the TLS transport stuff is being handled, where it would then need to consult the h.Headers.Request to see if the config mistake was made. A bit awkward, but it's the most correct way to handle it I think.

[yubiuser]

Thanks for the hint. I moved the check into the TLS section and used h.Headers.Request.Set to check if the users wanted to add Host upstream_hostport.

Do you want me to squash the commits into a single one?

[yubiuser]

CI test fail due to govulncheck now detects https://pkg.go.dev/vuln/GO-2026-4775 (published yesterday) and golangci-lint was updated to v2.11.4 on 22th or March.

Should those issues be addressed in a separate PR?

[francislavoie]

Thanks!

No need to squash, we'll squash on merge. We'll fix the lint separately then rebase and merge this when we're ready.