HTTP redirects look simple on the surface, but in production they become complex quickly when domain migrations, HTTPS enforcement, legacy URL compatibility, SEO behavior, method preservation and error states all converge. Choosing the wrong status code can break search engine indexing, browser cache behavior, API client logic or mobile application flows.
In many organizations, redirect rules live in multiple places at once: application code, web server configuration, CDN settings, load balancer rules or ad-hoc maintenance scripts. When multiple systems define redirects for the same domain, redirect loops, double-redirect chains, query string loss and wrong-target bugs become real risks.
The problem is even larger in legacy modernization projects. The old domain must forward to the new one, the old path structure maps to a new API layout, some paths need permanent redirects while others are temporary. Changing application code is slow and risky, and the legacy application often lacks the flexibility to support it at all.
The right approach is to manage redirect behavior as a traffic rule at a central point. Scheme, host, path, query, status code and error conditions should be defined at the ADC layer so the application can focus entirely on real business logic.
TR7 HTTP Redirect Rules deliver this model: HTTP→HTTPS transitions, full-URL redirects, domain and path migrations and error-code-triggered redirect flows are all managed in a single policy model.
TR7 turns HTTP redirects into manageable rules driven by scheme change, full URL target, error condition and traffic context.
The `redirect_scheme` action redirects HTTP traffic to HTTPS without modifying application code or web server configuration, establishing a secure connection standard centrally.
The `req_redirect_location` action forwards a request to a specific URL. Legacy domains, old paths or campaign links can all be migrated centrally to their new addresses.
A redirect rule can fire on timeout or response error codes, sending users to a maintenance, status or backup service page instead of a raw error response.
Host, path, method, header, source IP or FX expressions can drive the redirect decision. Different URL subtrees within the same vService can apply different redirect behaviors.
HTTP Redirect Rules consolidate redirect scenarios — from rapid HTTPS enforcement to error-code forwarding — under a single ADC policy.
HTTP-to-HTTPS redirection is a baseline security requirement for most applications. TR7 applies the scheme change as an ADC rule rather than as application code. Requests arriving over HTTP are forwarded to the HTTPS target; requests already on HTTPS do not generate a spurious redirect. This makes it straightforward to bring legacy applications up to secure publishing standards.
A legacy domain can be forwarded to a new domain, an old path to a new path, or a temporary campaign address to a permanent destination. TR7 keeps the full target URL definition inside the rule. This structure is critical in migration, rebranding and application modernization projects — the application code never has to deal with old URL knowledge.
Not every redirect carries the same semantics. 301 and 308 signal a permanent move; 302 and 307 signal a temporary redirect. 307 and 308 preserve the original request method, making them the right choice for API calls that must not have their method silently changed to GET. TR7 makes status code selection an explicit part of the rule, leaving no room for ambiguity in redirect behavior.
Whether the query string is forwarded to the redirect target is determined per rule. Legacy campaign links may need to carry query parameters for analytics or tracking. Security-sensitive parameters may not belong on the new target. TR7 makes this decision explicitly manageable inside the central rule.
API clients may send requests with POST, PUT or PATCH methods. A wrong redirect status code can cause the client to silently downgrade the method to GET, losing the request body. TR7 enables the use of method-preserving redirect behaviors such as 307 and 308. This matters in API modernization and endpoint migration scenarios.
A canonical direction can be established between `www.example.com` and `example.com`. This consistency benefits SEO, certificate scope, cookie domain and user experience. TR7 manages domain standardization without distributing the logic to the application or web server layer — one rule governs the entire vService behavior.
In legacy applications, paths such as `/old/products/123` may have moved to a different structure in the new application. TR7 path conditions allow old URL trees to be forwarded to new targets. This prevents broken bookmarks and integration links during incremental modernization, enabling a controlled handover to the new application while the old one is still running.
Flows similar to `error_redirect_at_tm` forward users to an alternative destination when a timeout or traffic management error occurs — for example, a maintenance page, a status page or a backup domain. Instead of exposing a raw error, a controlled experience is delivered. Operational outages are handled with more grace.
With the `error_redirect_at_res` approach, specific error codes returned by the backend can trigger a redirect. On 500, 502, 503 or 504 responses, users can be forwarded to a different page. This is particularly valuable for maintenance and temporary service-degradation scenarios — error handling becomes independent of the application.
Host, path, method, header, source IP or FX expressions can be used as redirect conditions. For example, only mobile paths, only a legacy API version or only traffic from specific geographies can be redirected. The redirect rule stops being a blunt global behavior and becomes a controlled, context-sensitive decision.
When redirect rules are spread across multiple systems, the chance of a loop grows. Because TR7 rules live in a single place, scheme, host and path conditions are more visible. Operators can more easily catch mistakes such as redirecting an already-HTTPS request back to HTTPS or bouncing back from the new domain to the old one — a critical safety net for production changes.
When redirect rules are managed as part of the traffic rules engine, the change history is traceable. Who redirected which domain, to which target, with which status code can be answered through the audit log. Incorrect redirects can be rolled back quickly. This creates a shared accountability layer for SEO, security and operations teams.
HTTP redirect rules are operated together with status code selection, query behavior, method preservation, error conditions, loop control and maintenance scenarios.
301 and 308 are used for permanent redirect behavior; 302 and 307 are used for temporary redirects. When method preservation is required for API calls, 307 or 308 is more appropriate. An incorrect status code can affect browser or client-side cache behavior and, in the case of 301, can become difficult to reverse once search engines have cached it.
Query parameters must either be forwarded to the redirect target or reconstructed there. Tracking parameters may need to be preserved; sensitive parameters should not be forwarded. This decision should be made based on security and analytics requirements, and should be stated explicitly in the rule rather than left to implicit platform defaults.
Some redirect status codes cause the client to change its method. For form submissions or API write operations this creates a risk of data loss or unintended processing. The appropriate status code must be selected for scenarios that require method preservation.
A timeout or response error code can trigger a redirect. These rules can be used for controlled forwarding to a maintenance or status page. Error redirects should not mask the underlying problem — they should be operated alongside logging and monitoring so the actual error source is tracked separately.
When writing a redirect rule, the operator should verify that the target URL does not re-trigger the same condition. Scheme, host and path conditions should be bounded clearly. Central rule management reduces loop risk by keeping all conditions in one visible place.
During planned maintenance, specific paths or an entire host can be redirected to a temporary maintenance page. Temporary status codes such as 302 or 307 are more appropriate in this scenario so clients do not cache the redirect permanently. After maintenance, the rule is disabled and traffic returns to its normal flow.
A legacy application may be published over HTTP. TR7 redirects HTTP requests to the HTTPS target without any changes to application code, establishing a secure connection standard across the service.
When rebranding or changing domains, legacy domain traffic can be moved to the new address. A permanent move is signaled explicitly using 301 or 308.
Old URL trees can be redirected to new application paths. User bookmarks and legacy integration links remain intact throughout the migration.
When a backend is temporarily unable to respond, users can be sent to a maintenance page instead of a raw error. An operational outage becomes a controlled user experience.
When POST or PUT calls are moved to a new API endpoint, 307 or 308 can be used to ensure the client method and request behavior are preserved.
HTTPS enforcement, domain migration, path redirects and error forwarding — all managed with zero application code changes. Let's walk through a live setup on your own services.