Skip to main content
This lesson shows how to implement an HTTP → HTTPS redirect using the Kubernetes Gateway API. A redirect returns a response to the client indicating the requested endpoint has moved; the client then follows the returned location (new scheme and/or port) to reach the application. Using the Gateway API’s RequestRedirect filter on an HTTP listener keeps the HTTP listener focused only on issuing redirects, while the HTTPS listener (with TLS configured on the Gateway) serves the actual application traffic.
A diagram titled "HTTP Redirect" showing a client sending requests to a gateway that routes traffic to a new endpoint (App-v2) with a 202 Accepted response and an old endpoint (App-v1) marked with a 301 Moved Permanently.
Why use this pattern?
  • Centralizes TLS termination and certificate management on the Gateway resource.
  • Ensures all plain HTTP traffic is consistently redirected to secure HTTPS.
  • Avoids forwarding insecure traffic to application backends.
  • Allows flexible control of redirect status codes (permanent vs temporary) and target ports/schemes.
How it works (high-level)
  1. The Gateway exposes a listener on port 80 (HTTP) and a listener on port 443 (HTTPS).
  2. An HTTPRoute attached to the Gateway’s HTTP section uses a RequestRedirect filter to return a redirect response (e.g., to https://...:443).
  3. A separate HTTPRoute attached to the Gateway’s HTTPS section handles actual traffic and forwards to backend services.
Implementation steps
  • Configure TLS on your Gateway (certificates, trust, etc.). The Gateway’s TLS configuration applies to the HTTPS listener.
  • Create an HTTPRoute for the HTTP section with a RequestRedirect filter that points to https and port 443.
  • Create an HTTPRoute for the HTTPS section that matches hostnames/paths and forwards to the service backend.
Example: HTTPRoute that issues the redirect
Notes about the HTTPRoute:
  • parentRefs with sectionName: http attaches this route to the Gateway’s HTTP listener.
  • The RequestRedirect filter returns the redirect immediately; it does not forward the request to any backend.
  • scheme and port define the new destination clients should use.
Example: HTTPRoute for the HTTPS listener (forwards to backend)
Notes about the HTTPS route:
  • Attach this to the Gateway’s HTTPS listener using sectionName: https.
  • Configure hostnames, matches (paths, methods, headers), and backendRefs normally, just like any other HTTPRoute.
  • TLS termination is handled by the Gateway (ensure your Gateway resource has the appropriate TLS configuration and certificates).
Status code guidance
Choose the appropriate redirect status code for your use case:
  • 301 — Moved Permanently: browsers and search engines may cache. Use when the resource permanently moved to HTTPS.
  • 302 — Found / Temporary Redirect: do not be treated as permanent by clients.
  • 308 — Permanent Redirect that preserves the HTTP method (useful for non-GET requests where method preservation matters).
Quick reference table Related links and references This redirect pattern ensures your HTTP listener’s only responsibility is to guide clients to HTTPS, while the HTTPS listener (with TLS configured on the Gateway) serves secure application traffic.

Watch Video