Feature Enhancement Request: Support Hash (#) Characters in F5 XC Redirect Route Destination URLs

Request Type: Product Enhancement / Feature Request
Product: F5 Distributed Cloud (XC)
Component: HTTP Load Balancer – Redirect Route
Priority: Medium
Feature Area: URL Redirect Configuration / GUI Validation

1. Feature Request Summary

Request F5 to enhance the F5 Distributed Cloud (XC) HTTP Load Balancer Redirect Route functionality to allow the hash (#) character in the destination URL field.

Currently, the XC GUI validation does not permit destination URLs containing hash fragments. This prevents administrators from configuring standard HTTP 301/302 redirects to applications that use hash-based client-side routing.

2. Current Behaviour

When configuring a Redirect Route in F5 XC, the destination URL field rejects URLs containing the # character.

Example destination URL:

https://www.example.com/#/application/dashboard

The XC GUI validation prevents this URL from being accepted, even though it is a valid browser destination URL.

This appears to be a URL validation limitation rather than an issue with the destination application.

3. Expected Behaviour

F5 XC should allow the # character and associated fragment path in the Redirect Route destination URL field.

Administrators should be able to configure standard HTTP 301/302 redirects to URLs containing fragments without requiring additional route objects or custom response configurations.

Expected redirect response:

• HTTP Status Code: 302 Found

• Location Header: https://www.example.com/#/application/dashboard

The browser should navigate to the complete destination URL, including the hash fragment.

4. Technical Use Case

Modern web applications, particularly Single Page Applications (SPAs), frequently use hash-based routing to navigate users directly to specific application pages.

For example:

• https://www.example.com/#/dashboard

• https://www.example.com/#/navigator/utility/overview

• https://www.example.com/#/application/settings

The inability to configure these URLs in the Redirect Route destination field restricts the native redirect functionality.

5. Current Workaround

An alternative implementation using a Custom Route Object with the Direct Response action can achieve the required redirection.

The configuration involves:

This approach has been successfully implemented and tested.

However, it introduces additional configuration overhead compared to using the standard Redirect Route functionality.

6. Requested Enhancement

We request F5 Product Engineering to:

1. Modify the Redirect Route GUI validation to accept the # character in destination URLs.

2. Support valid URL fragment identifiers and associated client-side routing paths.

3. Ensure the configured destination URL is correctly included in the HTTP Location response header.

4. Maintain compatibility with existing Redirect Route functionality and validation for invalid URLs.

5. Confirm whether the restriction exists in the underlying API/schema validation or is limited to GUI validation.

7. Business and Technical Impact

This limitation affects deployments involving modern web applications that use client-side routing and hash-based navigation.

Without native support, administrators must implement additional Custom Route Objects and Direct Response configurations to achieve a straightforward redirect requirement.

Addressing this limitation would:

• Simplify HTTP Load Balancer configuration.

• Reduce dependency on custom route workarounds.

• Improve the administrative experience.

• Support modern Single Page Applications (SPAs).

• Provide a consistent redirect configuration experience.

8. Request to F5

We request that this enhancement be evaluated by the F5 XC Product Engineering team and considered for inclusion in an upcoming release.