AlinsRan opened a new pull request, #2862:
URL: https://github.com/apache/apisix-ingress-controller/pull/2862
### Type of change:
- [x] Documentation
### What this PR does / why we need it:
A route attached to an HTTPS listener with `sectionName: https` is still
reachable over plaintext HTTP on the same host and path. That is expected with
the default `listener_port_match_mode: "off"`, but the documentation does not
say so, and the obvious remedy of switching to `auto` does not work on its own
either.
Two preconditions decide whether the mode takes effect, and neither is
documented:
**The Gateway listener port must equal the port APISIX listens on.**
`internal/controller/config/types.go` explains this in a code comment, and the
configuration reference says "only enable this when APISIX listens on the
declared ports", but it does not say what happens otherwise. Declaring the
client-facing `443` while APISIX listens on `9443` injects `server_port ==
443`, which matches nothing, so the route stops serving on both protocols. That
is worse than no isolation, and a Helm upgrade plus a ready pod gives no hint
of it.
**A listener with a hostname is never pinned to a port.**
`collectServerPortMatchPorts` skips listeners that set
`spec.listeners[].hostname`, and `shouldInjectServerPortVars` returns false
when the resulting set is empty. So a route attached only to hostname listeners
gets no `server_port` variable in any mode. That is deliberate and covered by
`TestTranslateHTTPRouteServerPortVars` ("auto mode: no injection when explicit
target listener has hostname"), and the reasoning holds for two listeners that
share a port and differ by hostname. It does not hold for the case here: a
hostname-less HTTP listener on another port still matches the same Host over
plaintext, because the route is isolated by host and the host is the same.
This PR documents both, adds a "Listener port matching" section to the
configuration reference, and links to it from the Gateway support table. No
behavior change.
Whether the second case should also emit a `server_port` variable when the
route explicitly targets a hostname listener is a design question I have
deliberately left open rather than changing a tested decision here. Happy to
open a separate issue for it if that is useful.
### Pre-submission checklist:
- [x] Did you explain what problem does this PR solve? Or what new features
have been added?
- [ ] Have you added corresponding test cases?
- [x] Have you modified the corresponding document?
- [x] Is this PR backward compatible?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
