HTTP redirects

What it means

An HTTP redirect is a response directing a client to another URI, usually through a Location header and a 3xx status. The status influences what method the client may use on the subsequent request. A 303 generally directs the next retrieval to GET (or HEAD for a HEAD request); 307 and 308 preserve the original method. For POST with 301 or 302, clients have historically been allowed to switch to GET, so a model cannot claim one universal POST transition.

Try it

Simulation — follow a redirect locally. Choose POST or HEAD, a 301/302/303/307/308 status and a client policy for POST under 301/302. Click Follow one hop to see method, target and body handling. Try a two-location loop; the scene stops when the path repeats instead of running forever. Select missing Location to inspect a halted chain. Reset clears the hop history and initial request.

How the mechanism works

Redirects are observable HTTP exchanges. A server-side rewrite, by contrast, may serve an internal target without issuing another client request. A 301/308 is intended for permanent redirection semantics; 302/307 are temporary. Method preservation is especially important for write requests: treating every redirect as GET can drop intended request semantics, while replaying an unsafe POST to an unexpected endpoint can have side effects. Clients need redirect safety policies beyond these simple rules.

The fixture only contains /start, /next and /done. When the map points back to an earlier URL, the loop is a modeled terminal result. Real clients additionally enforce origin/scheme security rules, hop limits, credential handling and policy constraints. An arbitrary redirect does not prove SEO consolidation or transfer of signals.

Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.

In practice

For a planned URL migration, map old and new canonical URLs and verify HTTP methods that your application actually supports. Preview representative GET, HEAD and state-changing methods in a controlled environment. Inspect one-hop and multi-hop chains, ensure destinations are approved, and watch for loops. Stop if a POST would be forwarded to an unreviewed origin, an HTTPS endpoint is invalid or the destination changes unexpectedly. Keep the prior routing configuration and rollback release available.

Limits and common mistakes

This finite model neither navigates the user's browser nor sends external requests. It does not model cache persistence, browser-specific credential stripping or complex 3xx interoperability. A new URL may not have the same authorization or privacy boundary as the old one.

Key takeaways

303 generally redirects a non-HEAD request with GET; 307 and 308 preserve the request method and body. Client treatment of POST under 301 and 302 can differ, so do not hard-code one unconditional outcome. Bound redirect hops, watch for loops and avoid sending sensitive bodies to unexpected origins.