envoyproxy
Consider adding a HTTPRouteFilterExtensionRef for Envoy Gateway
Description:
Describe the desired behavior, what scenario it enables and how it would be used.
The project has been able to add functionality not yet defined in the Gateway API using Extensions
However some features that naturally live at the rule level within a xRoute that are API specific, dont fit well within Policies such as
- Direct Response https://github.com/envoyproxy/gateway/issues/2714
- Regex Based Rewrites https://github.com/envoyproxy/gateway/issues/1794
- Body Transformations https://github.com/envoyproxy/envoy/issues/35783
Adding support for these features in the Gateway API will take time, since building a common API across multiple implementations is not a trivial task, however this is impacting users migrating to Envoy Gateway from other projects who are unable to do so because these common features dont exist yet
Raising this issue to propose adding a new CRD that can be attached to a HTTPRoute rule using the extensionRef field within HTTPRoute https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteFilter
for #2714 do we need to wait https://github.com/kubernetes-sigs/gateway-api/issues/2826?
for #2714 do we need to wait kubernetes-sigs/gateway-api#2826?
yah we can wait or implement this via an extension (highlighted in this PR)
Also consider using this for: https://github.com/envoyproxy/gateway/issues/3173
for #2714 do we need to wait kubernetes-sigs/gateway-api#2826?
yah we can wait or implement this via an extension (highlighted in this PR)
Upstream will not implement it before v1.3(which seems too long), +1 to the filter approach.
+1, reg naming, HTTPFilter feels like a safe umbrella term to stash all the features under
+1 on adding an umbrella HTTPFilter to hold all rule-specific features.
