[Feature]: Implementing new Redirect Policy

Please select the area the issue is related to

Gateway

Please select the aspect the issue is related to

Aspect/Other (Anything else which does not match above categories)

Suggested Feature

Add a Redirect policy to the WSO2 API Platform gateway that issues an HTTP redirect to the client directly at the gateway, implementing Gateway-API RequestRedirect semantics. When attached to an API or an individual operation, the policy runs in the request phase, builds a Location header from the incoming request combined with the configured overrides, and short-circuits the request with a configurable redirect status code (301, 302, 303, 307, or 308, defaulting to 302) — so the backend is never called. Only the components that are explicitly configured (scheme, hostname, port, and path) are overridden, while everything left unset (including the query string) is preserved from the original request, which keeps redirect rules concise and predictable. The path can be either fully replaced or rewritten by prefix, matching the Gateway-API path-modifier behavior.

The problem this solves is that the gateway currently has no first-class, declarative way to redirect clients without involving a backend. Common needs — migrating an API to a new host, upgrading insecure traffic from HTTP to HTTPS, rewriting to a canonical URL or path, or signalling that an endpoint has permanently moved — today require either implementing the redirect logic in every upstream service or crafting a manual immediate-response with a hand-built Location header, both of which are error-prone, duplicated across teams, and dependent on backend availability. A dedicated redirect policy centralizes this behavior at the gateway, produces the correct Location (including the scheme-aware default-port handling) automatically, and restricts responses to valid redirect status codes. It also closes a functional gap for Gateway-API conformance, where the RequestRedirect filter must be honored by the gateway itself rather than delegated downstream.

Related Issues

No response

Steps to Verify

• Design Document — A detailed design document has been created and reviewed, covering architecture, data flow, and edge cases.
• Design Mail — A design summary email has been sent to relevant stakeholders for awareness and feedback.
• Code Review — All code changes have been peer-reviewed and approved according to the project's review standards.
• Testing Complete — Adequate unit, integration, and/or end-to-end tests have been written and are passing.
• Documentation Review — User-facing and/or developer documentation has been updated to reflect the new feature and reviewed.
• Feature Complete — The feature is fully implemented, all checklist items above are done, and it is ready for release.