How to achieve hiding internal URLs and HTTP dynamic redirection with F5 XC HTTP Load Balancer

This is a comprehensive list of the XC options to change the Host or URL values in the requests and to trigger dynamic redirections.

XC HTTP LB basic rewrite options

By default, XC with or without a route rewrites the Host value of the client’s http request to the origin server’s FQDN name in the origin pool (only if the origin server is FQDN, not IP address).

Under the XC origin pool, you can control the SNI selection for the origin pool. Sometimes having not the correct SNI could generate 400 errors for nginx origin web servers, for example.

XC HTTP LB Host 3xx Redirection

Under the XC HTTP LB route, you can configure host redirection even for non standard port. If you don't configure an explicit path option, then XC will auto-redirect and keep the original URL. I found this not something well-explained.

For basic HTTP to HTTPS redirection you can easily enable it under and HTTPS LB and the only issue is it assumes that HTTP is on port 80, so for custom redirection from HTTP on port other than 80 you need to use the below methods.

For any F5 experts out there this is similar to the default http to https redirection in F5 BIG-IP ADC or F5 NEXT ADC with system iRule _sys_https_redirect.

You can even configure the HTTP LB to listen on ports other than the default ones (80 for HTTP or 443 for HTTPS) and to redirect to also not custom ports. In some cases you will need to add the FQDN domain with the non-custom port. Some web browsers send traffic to not custom ports with the port in the host name and this could cause XC not to match the traffic.

To test this with "curl" that can even be directed with the "resolve" option to HTTP LB that the public DNS still does not direct to it.

This is similar to F5 BIG-IP/NEXT iRule TCL scripting where " [HTTP::uri] " or " [HTTP::path] " are used depending if you want the redirect to keep the query parameters or not.

XC HTTP LB internal URL Rewrite

Under the XC HTTP Route advanced options, you can find the Request URL rewrite can match on prefix or even a regex to be used. This in some cases helps for apps that don't handle very well 3xx redirects (mobile apps are one such case) as for example "/test" URL is auto-changed to "/" otherwise 404 code would be seen if the page does not exist!

The rewrite option seems particularly useful for Customer Edge (CE) deployments that are inside the customer networks RE > CE traffic where the HTTP LB is on the RE and the origin servers in the origin pool are on the CE and the SSL/IPSEC tunnel between RE and CE is used to stich things.

Sometimes a rewrite of the response is needed, as for example to change the HTML response image urls to the new ones. In this case, Nginx containers can be used with XC Virtual Kubernetes (v8ks) that will offer this advanced function with the "filter" option that I have described in article F5 XC vk8s workload with Open Source Nginx | DevCentral

In F5 BIG-IP or NEXT with iRules or even Local Traffic Policies this functions are implemented.

XC Custom Route

Under Multi-Cloud App Connect, you can create custom route objects that can also do redirects or rewrite request URLs. The main benefit is that many HTTP LB can use the custom routes and can attach custom Request/Response headers or Cookies, even on Redirect routes that the Simple Routes that are directly created under the HTTP LB can't. This can be useful for some logic in mobile apps or custom non browser Agents like API clients.

Summary

The XC Cloud provides many options. In the future, you might see things like TCL iRule scripts that will offer advanced changes and rewrites of even HTTP request and response bodies without adding Nginx containers. So, keep checking release notes at Release Changelogs | F5 Distributed Cloud Technical Knowledge to not miss anything new that is released!