feat: add support for Gateway API HTTPRouteFilter

[tao12345666333]

HTTPRouteFilter defines processing steps that must be completed during the request or response lifecycle. HTTPRouteFilters are meant as an extension point to express processing that may be done in Gateway implementations. Some examples include request or response modification, implementing authentication strategies, rate-limiting, and traffic shaping. API guarantee/conformance is defined based on the type of the filter.

https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteFilter

HTTPRouteFilter can appear in HTTPBackendRef and HTTPRouteRule

Since they support different priorities, we can split the following steps to implement.

• HTTPRouteRule

  • Core feat: support redirect and requestHeaderModifier in HTTPRoute filter #1426
    • requestHeaderModifier: RequestHeaderModifier defines a schema for a filter that modifies request headers.
    • requestRedirect: RequestRedirect defines a schema for a filter that responds to the request with an HTTP redirection.
  • Extended
    • responseHeaderModifier: ResponseHeaderModifier defines a schema for a filter that modifies response headers.
    • requestMirror: RequestMirror defines a schema for a filter that mirrors requests. Requests are sent to the specified destination, but responses from that destination are ignored. feat: support HTTPRequestMirrorFilter in HTTPRoute #1461
    • urlRewrite: URLRewrite defines a schema for a filter that modifies a request during forwarding.
  • Implementation-specific
    • extensionRef: ExtensionRef is an optional, implementation-specific extension to the “filter” behavior. For example, resource “myroutefilter” in group “networking.example.net”). ExtensionRef MUST NOT be used for core and extended filters. NOTE: We do not currently have this plan.

• HTTPBackendRef

  • Core
    • requestHeaderModifier: RequestHeaderModifier defines a schema for a filter that modifies request headers.
    • requestRedirect: RequestRedirect defines a schema for a filter that responds to the request with an HTTP redirection.
  • Extended
    • responseHeaderModifier: ResponseHeaderModifier defines a schema for a filter that modifies response headers.
    • requestMirror: RequestMirror defines a schema for a filter that mirrors requests. Requests are sent to the specified destination, but responses from that destination are ignored.
    • urlRewrite: URLRewrite defines a schema for a filter that modifies a request during forwarding.
  • Implementation-specific
    • extensionRef: ExtensionRef is an optional, implementation-specific extension to the “filter” behavior. For example, resource “myroutefilter” in group “networking.example.net”). ExtensionRef MUST NOT be used for core and extended filters. NOTE: We do not currently have this plan.

[AlinsRan]

let me make it happen.

[AlinsRan]

The HTTPBackendRef.filters cannot be implemented at present, because the DP(APISIX) does not support filtering at the service level.

The responseHeaderModifier and urlRewrite features have not entered gateway-api v1beta1.

[incubator4]

The HTTPBackendRef.filters cannot be implemented at present, because the DP(APISIX) does not support filtering at the service level.

The responseHeaderModifier and urlRewrite features have not entered gateway-api v1beta1.

I saw gateway-api v0.5.1 have been merged, and I would love to finish part.

[AlinsRan]

I saw gateway-api v0.5.1 have been merged, and I would love to finish part.

Of course, do you have any ideas?

[incubator4]

I saw gateway-api v0.5.1 have been merged, and I would love to finish part.

Of course, do you have any ideas?

I've already read abount ingress controller about gateway implementation and how the apisix plugin is used.
The urlRewrite method should be implemented as same as headerModifer with apisix plugin proxy-rewrite.

By the way, I'm not sure that, according to the documentation of the gateway api, urlRewrite could also modify Header host.

Should I set host as same way as HeaderFilter, or implement new variable host,which was mentioned in proxy-rewrite doc ?

[tao12345666333]

@AlinsRan PTAL

[heesuk-ahn]

@tao12345666333

Are there any plans to support extensionRef yet?
Since API SIX has a plugin, I think it is possible to use it to implement extensionRef and link it to HttpRoute as a filter. 🤔

Each user may want to implement various Auth Filters, Rate Limits, etc (CustomFilter).

Our team also wants to enable use of Routes according to Token Verify or implement RateLimit, etc. To do this, custom implementation functions such as extensionRef are required. 🤔

I'd appreciate it if you could let me know if there's something I'm misunderstanding or if you have any ideas on how to implement it in a different way. 🙇

[heesuk-ahn]

In my opinion, using ApiSixRoute and custom plugin first, then migrating when Custom Filter is added later is also a way. 🤔

[tao12345666333]

@heesuk-ahn Sorry for the delay. I have too many notifications😅

There is no clear implementation plan for it yet, because currently our support for Gateway API is in Beta stage, and the Gateway API project is also in Beta stage.

We want to give priority to the stable and common requirements in the core, and the rest may change in the future to avoid bringing some breaking changes to users.

Now adding plugins through ApisixRoute should be able to meet the needs very well.

Also, is your team already using APISIX Ingress? Is it possible to add user case in powered-by.md file?

[heesuk-ahn]

@tao12345666333

thanks you for reply :)

as you say, we are going to use ApisixRoute and CustomPlugin first, and then in the future, if Gateway Api spec stable version released, we also can consider refactoring Gateway Api Spec :)

As an early user of APISIX Controller, we are just starting to introduce it, but we will add our case to powered-by.md.
Thank you for your contributions.