For example, if your organization wants to migrate your app to a newly registered domain, you can redirect traffic that is sent to the old domain to instead be sent to the new domain in the client browser. Or, if you have a long, complex URL for your app, you can surface a user-friendly URL instead and internally rewrite it to the complex URL.

To choose between client-side redirects and server-side rewrites, refer to the following table.

TypeRedirectRewrite
DescriptionRequest to one URL is sent client-side to another URL for the app.Server-side rewrite of the URL before the client request is forwarded to the app.
Exampleone.solo.io/myapp is changed to another.solo.io/mynewapp in the browser, and includes a 308 - Permanent Redirect response code.one.solo.io/myapp/cool-article is a user-friendly URL that is internally rewritten to the actual URL, another.solo.io/myapp.aspx?name=cool-article.
RouteTable fieldshttp.redirect.hostRedirect and http.redirect.pathRedirecthttp.forwardTo.hostRewrite and http.forwardTo.pathRewrite
Host behaviorOverwrites the host portion of the URL with another host. Optionally adds a redirect response code.After the original host and path are matched, replaces the “Authority/Host” header with another host before forwarding the request to the destination.
Path behaviorOverwrites the entire path portion of the URL with another path. Optionally adds a redirect response code.After the original path is matched, replaces it with another path before forwarding the request to the destination.

Redirect requests to hosts or paths

Overwrite the host or path with another host or path that the ingress gateway sends the request to. The client sees the redirect, for example, go from one URL to another URL in a browser. You can optionally add a redirect response code too. For more information, see the Gloo Mesh Gateway API docs for redirects.

Redirect requests to hosts

http.redirect.hostRedirect overwrites the host portion of the URL with another host. The ingress gateway directly sends the request to the destination that listens on the other host, without processing the original host.

  1. Follow a guide in Forward requests to a destination to set up routing for your intended host. For example, if your app used to listen on one.solo.io but now listens on another.solo.io, follow one of the guides to set up routing for your destination and specify another.solo.io as the host in the route table.

  2. Create a second route table to redirect requests from one host to the other host. This resource only specifies how host redirection occurs, and does not specify how routing occurs when the request reaches the app that listens on the second host. In this example route table, all requests to the one.solo.io host are redirected to another.solo.io.

      kubectl apply -n global -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: RouteTable
    metadata:
      name: redirect-host
      namespace: global
    spec:
      # First host to redirect traffic away from
      hosts:
        - 'one.solo.io'
      virtualGateways:
        - name: istio-ingressgateway
          namespace: bookinfo
          cluster: ${CLUSTER_NAME}
      http:
      # Second host to redirect traffic to
      - redirect:
          hostRedirect: another.solo.io
    EOF
      
  3. Test the redirection by accessing the old host and any specified paths. For example, curl or navigate to one.solo.io to verify that you are redirected to another.solo.io.

Redirect requests to paths

http.redirect.pathRedirect overwrites the entire path portion of the URL with another path. The ingress gateway directly sends the request to the destination that listens on the other path, without processing the original path.

  1. Follow a guide in Forward requests to a destination to set up routing for your intended path. For example, if your app used to listen on /one but now listens on /another, follow one of the guides to set up routing for your destination and specify /another as the path in the route’s matchers section.

  2. Edit your route table to add a redirect route section. This section matches the old route, and specifies the desired route to redirect requests to. In this example, the added route named redirect matches the old /one path, and redirects to the /another path. The existing route named myapp then specifies the normal routing rules for the app that listens on /another.

      ...
         http:
           # Redirect route
           - name: redirect
             # Prefix matching for the old path
             matchers:
             - uri:
                 prefix: /one
             # Redirection to the desired path
             redirect:
               pathRedirect: /another
           # App route
           - name: myapp
             # Prefix matching for the desired path
             matchers:
             - uri:
                 prefix: /another
             # Routing rules for app
             forwardTo:
               destinations:
                 - ref:
                     name: myapp
                     ...
      
  3. Test the redirection by accessing the host and the old path. For example, curl or navigate to <host>/one to verify that you are redirected to <host>/another.

Include response codes

You can optionally add an HTTP status code to the redirect response.

For example, to add a 307 - Temporary Redirect status code to your redirect response, add the following responseCode to the http.redirect section:

    http:
  - redirect:
      hostRedirect: another.solo.io
      # Temporary Redirect HTTP status code
      responseCode: TEMPORARY_REDIRECT
  

The following HTTP status codes are supported.

Redirect valueNumberHTTP status code
MOVED_PERMANENTLY0301 (default)
FOUND1302
SEE_OTHER2303
TEMPORARY_REDIRECT3307
PERMANENT_REDIRECT4308


For help in choosing a status code, check out this article.

Rewrite hosts or paths before forwarding requests

Specify the desired host or path that the ingress gateway must rewrite the original value to before forwarding the request to the destination. The client sees the original URL and does not see the rewrite, because the ingress gateway processes the rewrite internally. For more information, see the Gloo Mesh Gateway API docs for rewrites. The client sees the redirect, for example, go from one URL to another URL in a browser.

Rewrite hosts

After the original host and path are matched, http.forwardTo.hostRewrite replaces the “Authority/Host” header with another host before forwarding the request to that other host.

  1. Follow a guide in Forward requests to a destination to set up routing for your destination. When you create the route table, include the following:

    • In the route’s hosts section, list both the old and new hosts. For example, one.solo.io and another.solo.io.
    • In the route’s forwardTo section, specify the new host to rewrite the listed matchers to. For example, hostRewrite: another.solo.io.
      kubectl apply -n global -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: RouteTable
    metadata:
      name: rewrite-host
      namespace: global
    spec:
      # List both hosts
      hosts:
        - 'one.solo.io'
        - 'another.solo.io'
      virtualGateways:
        - name: istio-ingressgateway
          namespace: bookinfo
          cluster: ${CLUSTER_NAME}
      http:
      - name: myapp
        matchers:
        - uri:
            prefix: /myapp
        forwardTo:
          # Rewrite one.solo.io to another.solo.io, and forward all requests to the /myapp path to the myapp service
          hostRewrite: another.solo.io
          destinations:
          - ref:
              name: myapp
              namespace: global
              cluster: ${CLUSTER_NAME}
            port:
              number: 8090
            kind: SERVICE
    EOF
      
  2. Test the rewrite by accessing the old host and any app paths. For example, curl or navigate to one.solo.io/myapp to verify that you are redirected to another.solo.io/myapp.

Rewrite paths

After the original path is matched, http.forwardTo.pathRewrite replaces it with another path before forwarding the request to the other path.

  • ✅ For prefix matchers, the gateway replaces only the prefix portion of the path.
  • ✅ For exact matchers, the gateway replaces the whole path.
  • ❌ For regex matchers, rewriting is currently unsupported.

For more information about the supported matchers, see the path matching guide.

  1. Follow a guide in Forward requests to a destination to set up routing for your destination. When you create the route table, include the rewrite rules.

    • In the route’s matchers section, list both the old and new paths. In this example, prefix matching for both /one and /another are listed. Note: To rewrite a path to only a forward slash (/), you must include a trailing slash on the old path. For example, to rewrite from /path/page/ to only /page, you must include the trailing slash at the end of /path/page/. Or, to rewrite from /path/ to only /, you must include the trailing slash at the end of /path/.
    • In the route’s forwardTo section, specify the path to rewrite all other listed paths to. For example, pathRewrite: /another.
      kubectl apply -n global -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: RouteTable
    metadata:
      name: rewrite-path
      namespace: global
    spec:
      # Applies to any host; can indicate a specific domain
      hosts:
        - '*'
      virtualGateways:
        - name: istio-ingressgateway
          namespace: bookinfo
          cluster: ${CLUSTER_NAME}
      http:
      - name: myapp
        # List both paths
        matchers:
        - uri:
            prefix: /one
        - uri:
            prefix: /another
        forwardTo:
          # Rewrite /one to /another, and then forward all requests for /another to myapp
          pathRewrite: /another    
          destinations:
          - ref:
              name: myapp
              namespace: global
              cluster: ${CLUSTER_NAME}
            port:
              number: 8090
            kind: SERVICE
    EOF
      
  2. Test the rewrite by accessing the host and the old path. For example, for a prefix matcher rewrite, you might curl or navigate to <host>/one/foo to verify that you are redirected to <host>/another/foo.