Open
Conversation
This was referenced Oct 2, 2025
ejona86
reviewed
Nov 25, 2025
| - matcher: gRPC will not support this deprecated field. | ||
|
|
||
| We will also support per-route overrides via the | ||
| [`envoy.extensions.common.matching.v3.ExtensionWithMatcherPerRoute` |
Member
There was a problem hiding this comment.
So this means we can have filters defined wholly in the RouteConfiguration? The Listener would no longer enumerate all the filters being used.
Member
Author
There was a problem hiding this comment.
Yes, that's correct.
In the future, we'll also add ECDS support, which would be another way for the Listener to not enumerate all of the filters being used, even if there is no per-route override.
Contributor
There was a problem hiding this comment.
A39 says that
There must be at least one filter in the list, or the Listener resource will be NACKed.Is this no longer true ?Note that gRPC will not fail validation if the map key specifies a filter instance name that does not exist in the HttpConnectionManager filter list. This is because during an update, the xDS client code cannot know which HttpConnectionManager config is currently being used.Do we ignore such filters currently ? and will we continue doing so ?
Member
Author
There was a problem hiding this comment.
This gRFC does not modify A39 in any way. Both of those statements from A39 are still true.
ejona86
approved these changes
Dec 30, 2025
dfawley
approved these changes
Feb 12, 2026
copybara-service bot
pushed a commit
to grpc/grpc
that referenced
this pull request
Feb 14, 2026
…oute (#40938) Prior to this PR, we have a fairly convoluted mechanism for passing configs to xDS HTTP filters. The configs are passed via the service config, using internal-only parsing. This allows us to have a single stack of filters for all routes, where the config to use for each RPC is passed down to the filter via call context, which is set when choosing the xDS route. That mechanism was originally chosen way back when we implemented fault injection (our first xDS HTTP filter) to hedge against the possibility that we might want the functionality to be configurable via service config when not using xDS. However, that possibility has not materialized, so there's no real advantage in doing it that way, and there are a couple of disadvantages: it requires us to convert the xDS protos first to JSON and then parse the JSON, which is fairly inefficient, and it requires a hack in our filter stack code to handle the case where there are multiple instances of the same filter in a single stack. Now there is a new reason to change this mechanism: with the introduction of the xDS composite filter (see pending [gRFC A103](grpc/proposal#511)), the set of filters will no longer just be one-dimensional, so we would need to add more hierarchical structure to the service config representation, and we'd need to add even more hacks to the filter stack to allow each filter to figure out which part of the hierarchical service config representation to use. That complexity would push the current already-hacky approach into "untenable" territory. I am addressing that problem by switching to a model more similar to how Java and Go do things: instead of constructing a single filter chain and passing the configs to the filters via call context, we will now have the `ConfigSelector` generate a separate filter chain for each xDS route, so that each filter can be directly passed the config to use when it is instantiated, and the `ConfigSelector` will return the filter chain to the channel when it chooses the route for each RPC. This PR switches the client-side xDS code to use this new approach, controlled by an experiment. For now, I am making this change on the client side only. The server side will require a bit more work: today, there is only one filter chain for each incoming connection on the server side, so introducing a separate filter chain for each route will require us to split that up into two filter chains, and we don't currently have the machinery needed for that on the server side. For now, our priority is to get the composite filter and ext_proc working on the client side, so I am leaving the server side for a later PR. Closes #40938 COPYBARA_INTEGRATE_REVIEW=#40938 from markdroth:filter_configs_config_selector a673a64 PiperOrigin-RevId: 869929302
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
4 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.
No description provided.