AlinsRan commented on code in PR #2804:
URL:
https://github.com/apache/apisix-ingress-controller/pull/2804#discussion_r3636323953
##########
internal/adc/translator/translator.go:
##########
@@ -66,6 +66,27 @@ func hasExplicitListenerTarget(parentRefs
[]gatewayv1.ParentReference) bool {
return false
}
+// collectServerPortMatchPorts returns the set of listener ports that should be
+// enforced through a server_port var.
+//
+// Listeners carrying a hostname are isolated by that hostname (service.hosts),
+// which is the correct discriminator when several listeners share a single
port.
+// A server_port var adds no isolation for them and actively breaks routing: it
+// pins the route to the Gateway's declared listener port, which need not equal
+// the port APISIX actually accepts the connection on (node_listen), turning
+// every request into a 404. Only hostname-less listeners rely on port-based
+// isolation, so only their ports contribute here.
+func collectServerPortMatchPorts(listeners []gatewayv1.Listener)
map[int32]struct{} {
+ ports := make(map[int32]struct{})
+ for _, listener := range listeners {
+ if listener.Hostname != nil && *listener.Hostname != "" {
Review Comment:
Correction to my earlier reply here — I described a different branch. On
this PR the server_port handling was reworked in a5e18fff:
`collectServerPortMatchPorts` collects ports only from hostname-*less*
listeners, and hostname-carrying listeners are isolated by `service.hosts`
instead, so a hostname listener is no longer pinned to a `server_port` var.
For the exact multi-ParentRef case you raised (one route targeting both a
hostname and a hostname-less listener), the route can still end up with both
`service.hosts` (from the hostname listener) and a `server_port` var (from the
hostname-less listener) on the same object, which over-constrains it. So your
per-listener split suggestion may still be warranted there. I did not touch
this path in the current change — happy to take the split as a follow-up if
you'd like.
--
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]
