Decide whether an Application Gateway URL rewrite should reroute the request

Source facts

Application Gateway supports HTTP-header and URL rewriting on v2. Without path-map reevaluation, backend matching uses the original path; enabling reevaluation instead matches the rewritten path and can select a different backend pool.

Basic routing rules cannot enable reevaluation. Path-based rules need a conditional rewrite or a rewrite without reevaluation to avoid an endless evaluation cycle. A loop created dynamically by client input terminates the affected request with HTTP 500. Microsoft Learn.

Applicability

Identify the listener, routing-rule type, rewrite condition and intended backend. Keep URL presentation changes separate from deliberate traffic redistribution.

DSE recommendation

DSE recommends documenting an input path, rewritten path and expected backend for each representative case. Decide explicitly whether reevaluation belongs in that mapping. Review how each applicable rewrite terminates before applying the configuration. Include an unchanged-path case so the review does not focus only on requests expected to move.

Verification

Test the mapping in an approved environment and retain backend-side evidence of where each request arrived. Include boundary inputs that could repeatedly satisfy rewrite conditions. Check the returned status and destination together; a rewritten address alone does not demonstrate correct routing. Treat unexpected HTTP 500 responses as a reason to inspect the rewrite sequence before expanding the rollout.

Official references

Microsoft Learn: Rewrite HTTP headers and URL with Azure Application Gateway. Source retrieved September 9, 2026.