GEP-2895: Query Parameter Filter

[lianglli]

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

[k8s-ci-robot]

[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.

Needs approval from an approver in each of these files:

• geps/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

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.

[robscott]

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.

[costinm]

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.

[spacewander]

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

[LiorLieberman]

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.

AFAICT it is possible with lua filter in envoy (envoyproxy/envoy#2098) and there is a PR from 8 hours ago to support this on the Route level.

+1 to adding a section as Rob proposed though.

[lianglli]

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.

[lianglli]

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.

[mlavacca]

/cc @mlavacca

[mlavacca]

Thanks for this PR, @lianglli!

[costinm]

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.

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.

[lianglli]

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.

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.

[arkodg]

• suggest including all implementations outlined in https://gateway-api.sigs.k8s.io/implementations/#implementations . If they dont support it, NA or skipping it should be fine

[lianglli]

ok, I will check them specifically.

[robscott]

Hey @lianglli, we're working on scoping new features for v1.2, do you mind adding a comment to track support for this proposal in #3103?

[lianglli]

Hey @lianglli, we're working on scoping new features for v1.2, do you mind adding a comment to track support for this proposal in #3103?

Yes, I will add a comment about GEP-2895: Query Parameter Filter in the #3103 asap.

[shaneutt]

@lianglli checking in: where are we at with this one, what do you need in order to move forward?

[arkodg]

@lianglli checking in: where are we at with this one, what do you need in order to move forward?

@shaneutt ptal at #3103 (comment)

[shaneutt]

Awesome, thank you

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten