feat: add support for from-to-www-redirect

[chakravardhan]

What type of PR is this?

/kind feature

What this PR does / why we need it:

When the from-to-www-redirect annotation is encountered and set to "true", the translator generates a completely separate, dedicated HTTPRoute for the redirect.

Translation Logic:
When the from-to-www-redirect annotation is encountered and set to "true":

1. The translator generates a completely separate, dedicated HTTPRoute for the redirect listening on the alternative domain. For example, if the Ingress specifies example.com, this feature attaches a new HTTPRoute listening on www.example.com that returns a 308 permanent redirect to example.com.
2. The translator dynamically inspects the generated IR Gateway and injects a new Listener for the alternative domain. This ensures the Gateway accepts traffic for the redirect route.

Compatibility with permanent-redirect (#299)

There is a potential edge case where a user specifies both from-to-www-redirect and permanent-redirect on the same Ingress resource.

How this is handled:

• This PR (from-to-www-redirect) generates a completely separate HTTPRoute dedicated to the www/non-www redirect. Because they operate on different HTTPRoute objects or distinct hostnames, they do not overwrite each other during the Intermediate Representation (IR) generation. When emitted, the Gateway API handles this overlap natively and gracefully by selecting the most specific Hostname match for routing the request.

Testing

• Unit Tests: Added tests in redirect_test.go to verify route generation and hostname swapping.
• Integration Tests: Added an end-to-end from-to-www-redirect scenario in converter_test.go verifying the correct emission of dual Gateway listeners and appropriate side-car HTTPRoutes.

Which issue(s) this PR fixes:

Fixes #

Does this PR introduce a user-facing change?:

Add translation support for NGINX Ingress annotations  `from-to-www-redirect`.

[k8s-ci-robot]

Hi @chakravardhan. 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.

Details

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-sigs/prow repository.

[Stevenjin8]

/ok-to-test

[Stevenjin8]

@chakravardhan the from-www-redirect seems reasonable to me, but have you how it would work with #299? what happens if you have from-www-redirect and that the ones in #299? I'm hoping #299 merges soon. Otherwise, the implementation seems good at a quick glance.

As for force-ssl-redirect, I'm not sure if we want or event need this annotation. My understanding as follows:

1. User configures Ingress resource to point to TLS certs
2. Ingress NGINX creates a self signed cert for hosts that do not have a configured TLS cert
3. For requests with a host without a configured cert, ingress nginx will not redirect HTTP to HTTPS unless force-ssl-redirect is explicitly enabled.

The problem is that gateway API doesn't have a "listen on 443 with a runtime-generate self-signed cert". That is, we might redirect to HTTPS, but not have an HTTPS listener at all! Haven't looked at the code too much, but LMK what you think.

[chakravardhan]

@chakravardhan the from-www-redirect seems reasonable to me, but have you how it would work with #299? what happens if you have from-www-redirect and that the ones in #299? I'm hoping #299 merges soon. Otherwise, the implementation seems good at a quick glance.

As for force-ssl-redirect, I'm not sure if we want or event need this annotation. My understanding as follows:

1. User configures Ingress resource to point to TLS certs
2. Ingress NGINX creates a self signed cert for hosts that do not have a configured TLS cert
3. For requests with a host without a configured cert, ingress nginx will not redirect HTTP to HTTPS unless force-ssl-redirect is explicitly enabled.

The problem is that gateway API doesn't have a "listen on 443 with a runtime-generate self-signed cert". That is, we might redirect to HTTPS, but not have an HTTPS listener at all! Haven't looked at the code too much, but LMK what you think.

Thanks for your reply! @Stevenjin8

Regarding force-ssl-redirect:

You are absolutely right. Gateway API doesn't have the concept of generating self-signed listener certificates on the fly like NGINX does. If we force a redirect to 443 without actual TLS secrets configured, most Gateway implementations (like GKE) will just reject the route or fail to open the listener, leading to a broken state.
I completely agree that we don't need this annotation translation since the architecture paradigms don't align. I will drop force-ssl-redirect from this PR.

Regarding from-to-www-redirect and #299 compatibility:

In our current implementation, we generate an entirely separate HTTPRoute dedicated to the www redirect (e.g., routeName-www-redirect).

Because #299 adds RequestRedirect filters to the existing route based on the permanent-redirect annotation, these two features should naturally avoid stepping on each other's toes—one modifies the primary route, and the other creates an additional standalone route specifically for the WWW redirect.

If there is an overlap where a user configures both from-to-www-redirect and a manual permanent-redirect that also points to www, the Gateway API should handle this cleanly: the underlying controller will simply use the most specific matching rule (or fallback to the oldest creation timestamp) to cleanly serve the redirect, rather than crashing or causing route conflicts. wdyt?

[Stevenjin8]

@chakravardhan I don't think this is quite right. Do you mind writing an e2e/integration test just to verify that behavior is correct/taking a quick look at https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#redirect-fromto-www ?

For example, the annotation can redirect host.com to www.host.com and from www.host.com to host.com, depending on the initial configuration.

Also when I run it with

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: httpbin
                port:
                  number: 8000

I get

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: nginx
  namespace: default
spec:
  gatewayClassName: nginx
  listeners:
  - hostname: example.com
    name: example-com-http
    port: 80
    protocol: HTTP
status: {}
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: example-ingress-example-com
  namespace: default
spec:
  hostnames:
  - example.com
  parentRefs:
  - name: nginx
  rules:
  - backendRefs:
    - name: httpbin
      port: 8000
    matches:
    - path:
        type: PathPrefix
        value: /
    name: rule-0
status:
  parents: []
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: example-ingress-example-com-www-redirect
  namespace: default
spec:
  hostnames:
  - example.com
  parentRefs:
  - name: nginx
  rules:
  - filters:
    - requestRedirect:
        hostname: www.example.com
        statusCode: 308
      type: RequestRedirect
status:
  parents: null

We have two http routes with the same host name, the last httproute should be

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: example-ingress-example-com-www-redirect
  namespace: default
spec:
  hostnames:
-  - example.com
+  - www.example.com
  parentRefs:
  - name: nginx
  rules:
  - filters:
    - requestRedirect:
-        hostname: www.example.com
+        hostname: example.com
        statusCode: 308
      type: RequestRedirect
status:
  parents: null

Also, the gateway would need to be updated

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: nginx
  namespace: default
spec:
  gatewayClassName: nginx
  listeners:
  - hostname: example.com
    name: example-com-http
    port: 80
    protocol: HTTP
+ - hostname: www.example.com
+    name: www.example-com-http
+   port: 80
+   protocol: HTTP
status: {}

[chakravardhan]

Thanks @Stevenjin8, I misunderstood this!

I've pushed a fix that addresses both issues:

1. Redirect Direction: The redirect HTTPRoute now correctly listens on the alternative host (e.g., www.example.com) and redirects traffic to the primary Ingress host (e.g., example.com), and vice-versa.
2. Gateway Listeners: The translation logic now dynamically searches the Parent Gateway and injects a new Listener for the alternative hostname so that the Gateway accepts the traffic meant for the redirect route.
   I've also added an integration test in converter_test.go, which now passes and outputs the correct Gateway and HTTPRoutes.

[Stevenjin8]

@chakravardhan, integration tests go under ./e2e.

[chakravardhan]

@chakravardhan, integration tests go under ./e2e.

@Stevenjin8, Added the e2e Test.

I discovered that while ingress-nginx natively accepted and returned 308 (Permanent Redirect) for this annotation, the Kubernetes Gateway API specification enforces a strict validation that limits RequestRedirect status codes to exactly 301 or 302.

I've updated the translator to natively map the from-to-www-redirect config into the valid Gateway-compliant 301 status code, and verified this functionality end-to-end against an Istio cluster via the E2E framework.

[Stevenjin8]

@chakravardhan could you also have teh tests send to port 443?

[Stevenjin8]

I think my main point is that the listeners you create do no have tls certs configured and I'm pretty sure ingress nginx would do that.

[chakravardhan]

I think my main point is that the listeners you create do no have tls certs configured and I'm pretty sure ingress nginx would do that.

@Stevenjin8, Fixed this in the latest commit! The code scans the Gateway's existing listeners for the dstHost (the target domain), grabs its gatewayv1.ListenerTLSConfig (which contains the test-cert SecretRef), and successfully injects it into the newly generated https redirect Listener.

[Stevenjin8]

This will definitely conflict with #330, but I can figure that out.

[chakravardhan]

@chakravardhan please rebase

done

[bexxmodd]

@chakravardhan We'll need to rebase it again.

[chakravardhan]

@Stevenjin8, if this PR still makes sense, could you provide LGTM label on this? Thanks

[Stevenjin8]

@chakravardhan id rather not lgtm and approve the same PR. Could you get @bexxmodd or @spencerhance to take a look?

[bexxmodd]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bexxmodd, chakravardhan, Stevenjin8

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [Stevenjin8]

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