Istio 1.24.3 repairs mixed-case gateway route generation
A hostname-normalization problem could leave gateway route discovery stale. The patch illustrates the difference between accepted Kubernetes configuration and configuration a proxy can use.
A routing resource can exist in Kubernetes while the proxy rejects the configuration generated from it. That gap is especially confusing when the input difference is merely the capitalization of a hostname. Istio 1.24.3 repairs a mixed-case host interaction with gateway TLS redirects that could leave route discovery stale.
The February 12 release notes identify the bug as mixed-case Hosts in Gateway and TLS redirect producing stale RDS. Other repairs address ambient policies and several gateway-management problems. The route-generation failure is useful to examine because it crosses several configuration boundaries before becoming visible in traffic.
I accept Istio's operational cost when its identity and traffic controls justify running another distributed system. A patch like this shows part of that cost. The declared resource and the configuration accepted by Envoy are distinct states, and debugging needs to identify where they diverge.
Gateway configuration becomes proxy configuration
The archived Gateway reference describes listener ports, protocols and hostnames for a proxy at the mesh edge. A VirtualService binds to a gateway to control forwarding for the selected host and port. Both resources contribute information to the eventual traffic-handling configuration.
The reference defines httpsRedirect as sending a 301 response that asks an HTTP client to use HTTPS. This is an operation on the HTTP listener. It is related to the HTTPS listener and its hostnames, but it is not the same as terminating TLS or choosing a backend for an application request.
That interaction means hostname handling must stay consistent across the resources that contribute to a redirect and its corresponding virtual hosts. If one path distinguishes names that another path merges, configuration generation can produce a set of domains that the downstream proxy considers duplicates.
The linked issue 49638 gives a concrete earlier reproduction. Two VirtualServices differed in hostname capitalization. The reporter showed Envoy rejecting a RouteConfiguration because domain values were not unique and described the resulting RDS status as stale. This is evidence about the reported failure, not a claim that the issue's original version was 1.24.3.
The release note describes the fix delivered in today's patch branch. Linking the historical report helps explain the symptom while preserving the distinction between when a problem was reported and when a particular release includes its repair.
Redirects and forwarding have different observable outcomes
A plain HTTP request can exercise the redirect while a direct HTTPS request exercises TLS termination and forwarding. Those requests test different parts of the gateway contract. A working HTTPS backend path does not prove that the HTTP listener generated the correct redirect configuration.
The Gateway reference also distinguishes listener configuration from external exposure. Istio can configure a proxy to listen, while the user remains responsible for allowing traffic to reach those ports. A connection failure before the proxy and a rejected route update inside the proxy therefore require different explanations.
For the mixed-case problem, the reported duplicate-domain error provides evidence of a generated-configuration failure. Changing network exposure would not resolve that error. Similarly, the presence of both VirtualService objects in the API does not establish that Envoy accepted the resulting route set.
The useful state progression is from resource declaration through generation to proxy acceptance. Each transition can fail independently. Stale route discovery concerns the latter part of that progression, so looking only at the current YAML can leave the actual rejection unexplained.
I find this distinction worth preserving in mesh operations. A versioned routing policy is valuable because it can be inspected and reviewed, but its intended behavior still depends on the proxy accepting the translated configuration. Status and rejection messages provide evidence about that second contract.
The patch also repairs control over managed gateways
The same release fixes failure to patch managed gateway and waypoint Deployments during upgrades to 1.24. It separately repairs programming and status for a gateway whose istio.io/rev label uses a tag. Those are management-path problems, distinct from the mixed-case hostname bug.
An upgrade can appear incomplete for different reasons. The controller may fail to update the managed Deployment, or a running proxy may reject generated route configuration. The fact that both affect a gateway does not make them one failure mode.
Ambient-related fixes in the patch are similarly specific. The release includes corrections for overly strict PeerAuthentication and for multiple strict port rules becoming permissive. It also clarifies the status message when an AuthorizationPolicy attached to ztunnel includes layer-seven rules. Clearer status helps identify a mismatch between the policy and the component expected to enforce it.
These changes do not introduce a new routing API. They improve the correspondence between the existing resources and their effective behavior. For the hostname case, the concrete expected result is that a valid host and redirect configuration produces a route update the proxy accepts. The important observation is the accepted configuration and its redirect behavior, alongside the resource that requested it.