feat: Rewrite Host per backend when origins differ - #508
Open
mattdjenkinson wants to merge 3 commits into
Open
mattdjenkinson wants to merge 3 commits into
mattdjenkinson wants to merge 3 commits into
Conversation
A rule whose weighted backends need different Host rewrites could not be programmed: the rewrite lived on the rule, so the controller refused the pair and the proxy kept serving its previous configuration while reporting Pending. Envoy Gateway has accepted a hostname URLRewrite on an individual backendRef since v1.7.0, and gives each weighted cluster its own host_rewrite_literal; the only thing stopping the controller was this repository's HTTPRoute webhook. Key changes: - Put the Host rewrite on each backendRef when a rule's backends disagree, and drop any rule-level hostname rewrite so both never apply - Keep the single rule-scoped rewrite when backends agree, so existing routes are unchanged - Admit hostname-only URLRewrite on HTTPRoute backendRefs; HTTPProxy backend filters are unchanged
The proposal rested on Gateway API's webhook refusing URLRewrite on a backendRef. Gateway API v1.5 ships no such webhook; the refusal was this repository's own, and Envoy Gateway already supports the per-backend rewrite on the version the edge runs. Key changes: - Replace the upstream modifier proposal with per-backend rewrites - Explain why the Backend hostname modifier covers only part of the case - Record the session affinity caveat on Envoy Gateway v1.7.4 - Drop open questions that only applied to the upstream route
ecv
approved these changes
Sep 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A load balancer splitting weighted traffic between two origins on different hostnames could not be programmed: the Host rewrite each origin needs lived on the rule, so the controller refused the pair and the proxy kept serving its old configuration while reporting Pending. Envoy Gateway already supports a separate Host rewrite per backend on the version the edge runs, and the only thing in the way was our own HTTPRoute webhook. This puts the rewrite on each backend when a rule's backends disagree, keeps today's single rule-level rewrite when they agree so no existing load balancer changes, and lets the webhook admit a hostname-only rewrite on a backend. It also corrects the merged enhancement doc, which blamed the Gateway API webhook and proposed an upstream change we don't need.
Notes for reviewers
Rules whose origins differ now get a cluster per backend rather than one merged cluster. On Envoy Gateway v1.7.4 that means a consistent-hash load balancer keeps a client on one endpoint within an origin but not on the same origin; v1.8.4 and later pin it automatically. HTTPProxy users still cannot set their own rewrite on a backend, and a rule-level Host override still takes precedence over a backend's, since reversing that would change traffic for existing proxies that set both.
Test plan
Related to #473 and #481, and datum-cloud/enhancements#744.