A103: xDS Composite Filter #511
Conversation
| - matcher: gRPC will not support this deprecated field. | ||
|
|
||
| We will also support per-route overrides via the | ||
| [`envoy.extensions.common.matching.v3.ExtensionWithMatcherPerRoute` |
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.
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.
A103-xds-composite-filter.md
Outdated
| - `source.ip` | ||
| - `source.port` | ||
| - `connection.requested_server_name` | ||
| - `connection.tls_version` | ||
| - `connection.sha256_peer_certificate_digest` |
There was a problem hiding this comment.
How are these represented in a Struct? What is the format for these?
There was a problem hiding this comment.
These aren't encoded in a Struct, they're just string or integer values, as per the Envoy docs:
The text above that mentions google.protobuf.Struct is talking about the values of the xds.route_metadata.filter_metadata attribute, not about these attributes.
(This question made me notice an internal problem that might cause changes for xds.route_metadata.filter_metadata, but I'll follow up on that separately.)
|
|
||
| ### Filter Behavior | ||
|
|
||
| Because all of the CEL attributes that we are exposing are available |
There was a problem hiding this comment.
I need to think about this more in Java. This is harder for us than just processing it in the filter itself. I'll need to think about how we'd want to implement the approach mentioned here.
2 participants
No description provided.