AlinsRan opened a new pull request, #2861:
URL: https://github.com/apache/apisix-ingress-controller/pull/2861

   ### Type of change:
   
   - [x] Documentation
   
   ### What this PR does / why we need it:
   
   A wildcard `spec.rules[].host` such as `*.tenant.example.com` also matches 
`one.two.tenant.example.com`. Users expect it to cover a single label, because 
that is what the [Kubernetes Ingress 
documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#hostname-wildcards)
 describes, and report the multi-label match as a bug.
   
   The controller passes `rule.Host` to the APISIX `hosts` field unchanged 
(`internal/adc/translator/ingress.go`, where `NormalizeHosts` only lowercases 
and de-duplicates), and APISIX matches it as a reversed-domain suffix.
   
   This is not specific to APISIX and is not a regression. v1.8.4 does the same 
(`pkg/providers/ingress/translation/translator.go`, `route.Host = rule.Host`), 
and nginx documents the same semantics:
   
   > An asterisk can match several name parts. The name `*.example.org` matches 
not only `www.example.org` but `www.sub.example.org` as well.
   
   ingress-nginx emits `server_name *.example.org` directly, so it behaves 
identically. Narrowing the match would be a silent runtime break for anyone 
relying on it, with no apply-time signal, and would diverge from the most 
widely deployed Ingress implementation. Documenting it is the better trade.
   
   Gateway API is unaffected either way: `sigs.k8s.io/gateway-api` specifies 
wildcard hostnames as a multi-label suffix match, so `HTTPRoute` is already 
correct.
   
   ### 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]

Reply via email to