Remove code TODO for "support all standard HTTPRouteRule Filters"

[mlavacca]

Is there an existing issue for this?

• I have searched the existing issues

Problem Statement

In the context of the conformance tests, #2776 has introduced support for HTTPRouteRule.Filters of type RequestHeaderModifier. This has been achieved using a request-modifier kong plugin. Since RequestHeaderModifier is only one among the possible standard HTTPRouteRule.Filters, we should support all of them.

Proposed Solution

Implementation of filters handled in separate issues

• convert the core filter RequestRedirect to the proper Kong plugin #2799
• support GWAPI extended filters RequestMirror and URLRewrite #2800

This issue is only to remove the code TODO as filter implementation is already accounted for on our roadmap.

Additional information

No response

Acceptance Criteria

• remove the TODO in the code

[mflendrich]

@mlavacca, could you please split the core and extended filters into 2 separate issues, and add the core ones to Milestone 3 and the rest to Milestone 4? thx

RequestRedirect is currently not well understood so it might be worth labeling a spike.

[rainest]

For RequestRedirect, Kong routes do not have native configuration that will issue a redirect response. We furthermore do not have any plugin tailored for this purpose. There are two options to handle this currently:

• Use the serverless plugin, which effectively allows you to write your own plugin as plugin configuration instead of files on the image filesystem. IMO we should avoid this because we recommend against enabling this plugin for security reasons.
• Use a combination of request-termination (to issue a response with a chosen status) and response-transformer (to set a Location header). This would not support dynamic redirects that use part of the original request in the redirect location.

Any code we write for the serverless option is effectively plugin code. Our eventual goal should be to have a plugin in Kong's default plugin set that can handle dynamic redirects (replacing only part of the request as described by https://gateway-api.sigs.k8s.io/guides/http-redirect-rewrite/#redirects).

[shaneutt]

Given the note that the serverless plugin is a security risk, it would seem that is an option we shouldn't take at all. It would seem to me that if the second option is work-able for the current core requirements and conformance than we should start there and follow up with the "full" option described at the end.