Include port in X-Forwarded-Host header if its not the standard port for the scheme

[jwgmeligmeyling]

According to the Forwarded spec:

The syntax for a "host" value, after potential quoted-string
unescaping, MUST conform to the Host ABNF described in Section 5.4 of
[RFC7230].

Then, Mozilla's MDN documents the X-Forwarded-Host syntax ambiguously. First is states:

The X-Forwarded-Host (XFH) header is a de-facto standard header for identifying the original host requested by the client in the Host HTTP request header.

which seems to imply both Host and X-Forwarded-Host use the same syntax (as specified in Forwarded). But then on the Syntax section it's specified as:

X-Forwarded-Host: <host>

which is different from the MDN spec for Host:

Host: <host>:<port>

X-Forwarded-Host is a de facto standard so we could be debating forever. Per the Forwarded spec, I think X-Forwarded-Host should allow setting a port.

The above gist from Akka applies to Charon as well. The X-Forwarded-Host header set by the requestProxyHeadersRewriter currently only contains the host name. While requestProxyHeadersRewriter also sets X-Forwarded-Port, some applications expect the port in the X-Forwarded-Host header.

[mkopylec]

Different sources have different statements about what should the X-Forwarded-Host header contain. I think we can choose the RFC spec as our source of truth which is https://datatracker.ietf.org/doc/html/rfc7239#section-5.3

The "host" parameter is used to forward the original value of the
"Host" header field. This can be used, for example, by the origin
server if a reverse proxy is rewriting the "Host" header field to
some internal host name.

According to the above statement Charon can just set the original Host header as a value of X-Forwarded-Host header.
Does this idea solve your issue?