gateway-api
gateway-api copied to clipboard
kubernetes-sigs
GEP-2895: Query Parameter Filter
What type of PR is this? /kind gep
What this PR does / why we need it:
The HTTPRouteFilter API now supports filters RequestHeaderModifier and ResponseHeaderModifier.
This GEP proposes adding support for modifying query parameters in a HTTPRoute.
Which issue(s) this PR fixes: Fixes #2895
Does this PR introduce a user-facing change?:
NONE
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: lianglli Once this PR has been reviewed and has the lgtm label, please assign youngnick for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Hi @lianglli. Thanks for your PR.
I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Hey @lianglli, we're still very focused on getting v1.1 out the door so won't have time for a thorough review until after that's released. With that said, I'd recommend adding a section that shows which underlying implementations would support this. As far as I can tell, NGINX would and Envoy would not. It would be worth confirming that + looking at other common dataplanes like HAProxy to understand how widely implementable an API like this would be.
I was wondering: do we have WG participants who work on or have expertise in Nginx, HAProxy, Apache, caddy, traefik and the other data plane implementations ? I know Envoy is over represented, so not a problem - but it would be worth having some wiki page with various data planes - and few names that can provide review/feedback.
And maybe a common checklist for each proposal - to formalize a bit more the process of making sure the features and APIs we add are implementable.
I was wondering: do we have WG participants who work on or have expertise in Nginx, HAProxy, Apache, caddy, traefik and the other data plane implementations ? I know Envoy is over represented, so not a problem - but it would be worth having some wiki page with various data planes - and few names that can provide review/feedback.
And maybe a common checklist for each proposal - to formalize a bit more the process of making sure the features and APIs we add are implementable.
I would like to help in this WG. Both Envoy and Nginx are my specialties.
I was the core developer of Apache APISIX, which is a popular gateway built upon Nginx: https://github.com/apache/apisix https://github.com/apache/apisix/graphs/contributors.
Nowadays, I am working on Envoy-based gateway. I have contributed some code to Envoy: https://github.com/envoyproxy/envoy/commits?author=spacewander, especially on the Golang filter: https://github.com/envoyproxy/envoy/blob/d1e95536aec14330a4235ad888246868d686cfac/CODEOWNERS#L383
I was wondering: do we have WG participants who work on or have expertise in Nginx, HAProxy, Apache, caddy, traefik and the other data plane implementations ? I know Envoy is over represented, so not a problem - but it would be worth having some wiki page with various data planes - and few names that can provide review/feedback.
And maybe a common checklist for each proposal - to formalize a bit more the process of making sure the features and APIs we add are implementable.
Pls. check the "## Prior Art" and "## References" of this PR specifically.
Moreover, the HTTPQueryParamFilter is considered an extended feature.
BTW, I'm the core developer of Tengine and Tengine-Ingress.
Hey @lianglli, we're still very focused on getting v1.1 out the door so won't have time for a thorough review until after that's released. With that said, I'd recommend adding a section that shows which underlying implementations would support this. As far as I can tell, NGINX would and Envoy would not. It would be worth confirming that + looking at other common dataplanes like HAProxy to understand how widely implementable an API like this would be.
Currently, both the KONG and Traefik support Query Parameter Modification based on its plugin. And, it is natively supported by Tengine-Ingress.
I was wondering: do we have WG participants who work on or have expertise in Nginx, HAProxy, Apache, caddy, traefik and the other data plane implementations ? I know Envoy is over represented, so not a problem - but it would be worth having some wiki page with various data planes - and few names that can provide review/feedback. And maybe a common checklist for each proposal - to formalize a bit more the process of making sure the features and APIs we add are implementable.
Pls. check the "## Prior Art" and "## References" of this PR specifically. Moreover, the
HTTPQueryParamFilteris considered an extended feature.BTW, I'm the core developer of Tengine and Tengine-Ingress.
I'm not familiar with Tengine - is it based on Nginx ?
My question is more about having all "upstream" proxies that are used by different implementations ( nginx, envoy, all 'native' ones in rust/go/etc) - and info if it supports or not that feature.
Adding optional features that are only supported by a few implementations is possible (I personally don't think it's right, but it's what this WG has decided), but I think there is a significant cost on the users and portability of the configs, so at least we should have the info.
I was wondering: do we have WG participants who work on or have expertise in Nginx, HAProxy, Apache, caddy, traefik and the other data plane implementations ? I know Envoy is over represented, so not a problem - but it would be worth having some wiki page with various data planes - and few names that can provide review/feedback. And maybe a common checklist for each proposal - to formalize a bit more the process of making sure the features and APIs we add are implementable.
Pls. check the "## Prior Art" and "## References" of this PR specifically. Moreover, the
HTTPQueryParamFilteris considered an extended feature. BTW, I'm the core developer of Tengine and Tengine-Ingress.I'm not familiar with Tengine - is it based on Nginx ?
My question is more about having all "upstream" proxies that are used by different implementations ( nginx, envoy, all 'native' ones in rust/go/etc) - and info if it supports or not that feature.
Adding optional features that are only supported by a few implementations is possible (I personally don't think it's right, but it's what this WG has decided), but I think there is a significant cost on the users and portability of the configs, so at least we should have the info.
Yes, Tengine is based on nginx core with many advanced features (E.g., H3/QUIC , asynchronous SSL).
I got your concern.
However, the gateway-api is the next specification about L4 ~ L7 network routing in cloud-native. This spec should cover all core elements in RFC.
The query parameters are an important part of the request URL. The developers can use query parameters to filter, sort or customize data of request body. Backend service can enable different function based on the query parameters. Query parameters are important information about search and track. Moreover, query parameter, headers and cookies are common techniques used in a canary release.
Just like modify header is useful, the same goes for query parameters.
At last, there are many requirements about 'Query Parameter Filter' in real internet world.