Further clarification on hostname matching and forwarding when Host header includes a port

[sunjayBhatia]

What would you like to be added:
In #1980 we added clarification that implementations MUST ignore a port included in the HTTP Host header.

Implicitly, the test added also asserts that the backend will receive the original Host header with the port intact (e.g. the test/request with Host: very.specific.com:1234 will forward that Host header unchanged to the backend).

Is this a desired behavior? If so, we should explicitly document it in the API spec so users/implementers expect it. If not, again we should document it.

Why this is needed:
Specificity in the API documentation/tests.

Further Notes:

• Contour at the moment (and I believe at least Envoy Gateway) strips any port from the host header and does not forward it to the backend.
• We added this port strip behavior in Contour to ensure we can do wildcard hostname matching in Envoy, Envoy only allows a wildcard prefix or suffix hostname match, *.foo.com or foo.com:* but not *.foo.com:*. We can likely come up with an implementation that fulfills whatever spec, but just noting this as Envoy-based implementations may not be conformant with this test for a bit depending on how they are implemented and what is decided. See here
• It looks like Istio has a similar issue as described above, since Envoy does not allow double-ended wildcard hostname matching, from here

[howardjohn]

IMO it is desired, we should not modify the user's request.

For envoy you want IgnorePortInHostMatching

[sunjayBhatia]

Ah nice, thats a new field since I looked at this last 💯