Redirects and rewrites

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.

Redirect requests to hosts or paths link

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 Enterprise API docs for redirects.

Redirect requests to hosts link

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 --context $REMOTE_CONTEXT1 -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: gloo-mesh
         cluster: ${REMOTE_CLUSTER1}
     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 link

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 link

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.

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

Rewrite hosts or paths before forwarding requests link

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 Enterprise API docs for rewrites. The client sees the redirect, for example, go from one URL to another URL in a browser.

Rewrite hosts link

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 --context $REMOTE_CONTEXT1 -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: gloo-mesh
         cluster: ${REMOTE_CLUSTER1}
     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: ${REMOTE_CLUSTER1}
           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 link

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.