HTTP redirects

How it works

A redirect response can include a Location URI reference. The client resolves a relative reference against the current request URI, but the response does not itself force a new request. If the client follows, the status and client behavior determine the method at the next hop. In particular, 301 and 302 permit POST-to-GET conversion; 307 and 308 preserve the current method during automatic redirection. See RFC 9110’s redirect semantics.

Track the method as state. Suppose the original POST encounters a 302 and the client chooses the permitted POST-to-GET behavior. The next request is GET; a subsequent 307 preserves GET, not the historical POST. By contrast, if the first hop is 307, the next request retains POST and its content if the client follows. These differences matter when a chain crosses origins or touches a state-changing endpoint; the model does not replay real requests.

A worked example

In the baseline simulation, POST /start receives a 302 with Location /next. The selected client policy converts POST to GET, so the next request is GET /next. Its 307 points to /final and preserves that current GET, producing GET /final. The second redirect preserves what it receives, not the original POST.

What changes the conclusion

A server-internal rewrite is different: the server maps a request internally rather than sending the client an HTTP redirect to follow. An address change in a configuration alone therefore does not establish that a new client request occurred. Apache’s rewrite examples illustrate the distinction.

In practice

For a real service, first obtain permission and inspect existing response records or a read-only trace: note each request method, response status, and Location. If a redirect was not followed, the next response is unknown, not a confirmed failure. A loop, an invalid target, a client’s choice not to follow, or an unavailable destination can produce different problems; the symptom alone does not identify which one occurred. Do not automatically replay a state-changing POST as a test.

When inspecting a production chain with authorization, record the method, effective URI, response status and Location at every observed hop. Stop on unknown or unobserved next responses rather than declaring success. Avoid automatic replay of sensitive POST bodies to unexpected targets, and validate that a proposed redirect does not loop before enabling it.

Limits and unknowns

The simulation uses predefined routes and stops on an invalid Location fixture or a detected loop; it does not walk arbitrary redirect chains or enforce a numeric hop limit. A stopped or unevaluated next step is not a confirmed negative response from a destination. Likewise, a successful simulated trace does not establish that a real service works.

What to take away

Diagnose redirects one response at a time: status and client behavior determine the next URI and method, and each next request becomes the input to the following step. If the trace stops or the destination is unknown, no later result has been established. A synthetic two-hop success cannot substitute for a read-only observation of the real service.