Learn Multigress - Advanced Routing & Request Transformation

#Introduction

You've mastered basic routing. Now it's time to manipulate the request itself. Episode 8 covers advanced routing and request transformation: modifying headers, redirecting and rewriting paths, evaluating complex routing conditions, and serving non-HTTP protocols like gRPC and WebSocket.

#Header Manipulation, Redirects, and Rewrites

#RequestHeaderModifier

The RequestHeaderModifier filter adds, changes, or removes headers before the request reaches the backend:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
    - name: main-gateway
      namespace: multigress-system
  rules:
    - backendRefs:
        - name: api
          port: 8080
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            set:
              - name: X-Forwarded-For
                value: "true"
            add:
              - name: X-Client-Region
                value: "id"
            remove:
              - "X-Internal-Token"

With the filter above, the proxy adds the X-Client-Region header before forwarding to the api Service. The kubectl apply -f route.yaml command applies this transformation immediately, with no backend restart needed.

#RequestRedirect and URLRewrite

There are two filters that look similar at first glance but serve different purposes:

• RequestRedirect: sends the client to a new URL (host and scheme changes), usually for HTTPS.
• URLRewrite: replaces the path at the gateway but keeps a single connection — the client doesn't know.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: https-redirect
spec:
  parentRefs:
    - name: main-gateway
      namespace: multigress-system
  rules:
    - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 301

The route above changes all HTTP requests to HTTPS. And for rewriting an old path to a new one:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: rewrite-route
spec:
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/v2
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /v2
      backendRefs:
        - name: api
          port: 8080

A request to /api/v2/users will be forwarded as /v2/users to the backend. With ReplacePrefixMatch, the backend doesn't need to know the old path was named v2.

#Conditional Routing with Route Rules

#Matching Based on Header, Query, and Method

HTTPRoute rules can be conditioned on more than just path. The following combination routes requests based on header and method:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: booking-route
spec:
  parentRefs:
    - name: main-gateway
  rules:
    - matches:
        - headers:
            - type: Exact
              name: X-Canary
              value: "true"
          method: GET
      backendRefs:
        - name: booking-canary
          port: 8080
    - backendRefs:
        - name: booking-stable
          port: 8080

Clients that send the X-Canary: true header with the GET method are routed to booking-canary; everyone else goes to booking-stable. This is the header-based canary pattern often used for internal testing.

Some important rules about matching:

• All conditions within a single match must all be satisfied.
• Multiple matches are OR'd; the first matching rule wins.
• method and queryParams are also available as conditions.

#Supporting gRPC and WebSocket

#GRPCRoute for gRPC

gRPC uses HTTP/2 and method terms like /service.Method. Its route uses GRPCRoute with matching based on service and method:

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: grpc-route
spec:
  parentRefs:
    - name: main-gateway
      namespace: multigress-system
  hostnames:
    - "grpc.example.com"
  rules:
    - matches:
        - method:
            type: Exact
            service: com.example.payment.PaymentService
            method: Charge
      backendRefs:
        - name: payment-grpc
          port: 9000

GRPCRoute uses the same structure as HTTPRoute, only its matching is based on gRPC service and method.

#WebSocket in HTTPRoute

WebSocket doesn't need a special route — its handshake is a regular HTTP request with an upgrade header. As long as the HTTPRoute points to the right Service, the upgrade will be forwarded, and a 101 Switching Protocols status indicates the connection was successfully upgraded.

#Closing

Episode 8 completes your routing capabilities: header transformation, redirects and rewrites, conditional routing based on headers and methods, and gRPC and WebSocket protocol support that flows smoothly through the gateway.

The key takeaways:

• RequestHeaderModifier adds, changes, and removes headers at the gateway.
• RequestRedirect changes the client destination; URLRewrite replaces the internal path.
• Matches can be combined with headers, query, and method; the first rule wins.
• gRPC uses GRPCRoute with service- and method-based matching.
• WebSocket just needs a regular HTTPRoute pointing to the right Service with an upgrade header.

In the next episode 9 we'll discuss canary deployments & progressive delivery — traffic shifting with weights, observability feedback loops for deployment safety, and integration with Argo Rollouts and Flagger. The route rules you just learned will become the primary tool in this episode.