HTTP Redirects

Why it matters

Redirects sit on critical paths: HTTP to HTTPS, old links after a redesign, login and logout, payment returns, API version changes. When one is wrong, the symptoms are confusing: form data lost because a POST became a GET, a page that redirects until the browser gives up, old links ending on a 404, or a wrong permanent redirect that browsers keep following after the fix because they cached it.

Redirects are also a security topic: an application that redirects to any URL a parameter contains lets anyone build a link on your trusted domain that lands on a phishing page. Browsers follow redirects silently, so these defects stay hidden unless a tester looks at every hop.

Five codes, two questions

In RFC 9110, permanent (301, 308) means the resource has a new permanent URL that future references ought to use: search engines and other crawlers update their links to it, and caches may store the redirect even without caching headers. Temporary (302, 307) means the original URL stays valid. 303 is neither: it points to another resource that holds the answer to this request. The temporary codes and 303 are cached only when caching headers allow it.

On the method, RFC 9110 notes that for historical reasons a client may change POST to GET when following a 301 or 302, and browsers do so under the Fetch Standard, dropping the body. 307 and 308 forbid it: the client must repeat the same method with the same body.

• 301 Moved Permanently: permanent; a POST may become a GET. For pages that moved for good.
• 302 Found: temporary; a POST may become a GET. For a short detour, such as to the login page.
• 303 See Other: the next request is a GET (a HEAD stays a HEAD). For the result page after a form POST (Post/Redirect/Get), so a refresh does not resubmit it.
• 307 Temporary Redirect: temporary; method and body kept. For a temporary move of a POST endpoint.
• 308 Permanent Redirect: permanent; method and body kept. For an API endpoint that moved for good.
• 304 Not Modified is also a 3xx code, but it sends the client nowhere new: it has no Location and tells the client to reuse its cached copy after a conditional request (RFC 9110 calls this redirection to a previously stored result), as in the caching lesson.

Try it: HTTP Status Code Lookup

Worked example: an order lost in a redirect

You met this defect as row R8 of the exercise in HTTP status codes: an app followed a 301 with a GET, and the chain ended in a misleading 200. Here is how it looks in the browser, hop by hop. A web shop moves its order API from /api/v1/orders to /api/v2/orders and adds a 301 from the old path for pages still open in customers' browsers. Those customers then press "Place order" and see "Something went wrong". In DevTools, with "Preserve log" on, the Network panel shows two requests for one click (see the trace below).

The browser followed the 301 as the Fetch Standard requires for a POST: it sent a GET without the body, and the page only saw the final 405. The bug report lists both hops and names the likely cause, 301 instead of 308. After the fix, the confirmation test checks that the POST reaches v2 with its body, returns 201 Created and creates exactly one order.

Outside the browser, curl -i shows the redirect response itself, since curl follows redirects only with -L; the Redirect Checker lists every hop of a public URL, requesting each hop with GET. For every redirect, check:

• Status: the exact code the requirement needs, not just any 3xx.
• Location: the right target, on https, keeping path and query string when it should (/old?id=7 → /new?id=7).
• Hops: as few as possible, ideally one.
• End: the expected page or resource, not a 404 or a login page.
• Method and body: what actually arrived after a redirected POST.

--- request 1 (the click) ---
POST /api/v1/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json

{"sku":"A-100","qty":2}

HTTP/1.1 301 Moved Permanently
Location: /api/v2/orders

--- request 2 (sent by the browser: method changed, body dropped) ---
GET /api/v2/orders HTTP/1.1
Host: shop.example.com

HTTP/1.1 405 Method Not Allowed
Allow: POST

Try it: cURL Generator Try it: HTTP Headers Parser

Redirect chains and loops

A redirect chain is several redirects in a row: http://example.com/shoes → https://example.com/shoes → https://www.example.com/shoes → https://www.example.com/shoes/. Each hop costs an extra round trip and is one more rule that can break. Chains grow in layers: a load balancer upgrades to HTTPS, the web server adds www, the application adds a trailing slash. Send every old URL straight to its final address instead.

A redirect loop is a chain that never ends. Browsers give up (the Fetch Standard stops at 20 redirects) and show an error such as ERR_TOO_MANY_REDIRECTS in Chrome. Loops come from two components that disagree:

• A proxy or load balancer accepts HTTPS but forwards the request to the application over plain HTTP; the application, which also forces HTTPS, sees HTTP and redirects to the same https address again, on every request.
• The web server adds a trailing slash and the application removes it.
• The login page sends signed-in users to the dashboard, which sends users it treats as signed out back to login, for example because the session cookie was set for another domain or path.

Try it: Redirect Checker

The open redirect risk

Many applications redirect to a URL taken from the request: after login, ?next=/orders/15 returns the user to the page they wanted. If any value is accepted, https://shop.example.com/login?next=https://example.org/ sends users from your trusted domain to any site. This open redirect (or unvalidated redirect) serves phishing well, because the link starts with your real domain.

The OWASP cheat sheet on unvalidated redirects recommends avoiding user-supplied targets, mapping a short id to a URL kept on the server, or checking the target against an allow-list. Test only systems you own or have written permission to test, in a test environment, with the reserved domain example.org as the outside target. Try each value below; expect a page of your own site or a safe default every time.

• An absolute URL: https://example.org/.
• A protocol-relative URL, which browsers treat as external: //example.org/.
• A lookalike that starts with your domain: https://shop.example.com.example.org/.
• Your domain as user info before @, which still leads to example.org: https://shop.example.com@example.org/.
• Other places: parameters such as returnUrl or redirect, logout and payment-return pages.

Try it: URL Parser

Frequently asked questions

References

• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• Fetch StandardWHATWGDefines CORS: preflight requests, the Access-Control-* headers and which responses a browser may expose to a page.
• OWASP Cheat Sheet Series: Unvalidated Redirects and ForwardsOWASP FoundationOpen redirects: why a redirect target must not come from user input, and the defences — server-side mapping of identifiers to URLs, allow-lists and confirmation pages.
• Redirections in HTTP — MDNMDN Web Docs (Mozilla)HTTP redirects: 3xx status codes with a Location header, permanent (301, 308) versus temporary (302, 303, 307), and how redirect loops arise.