Location header: relative vs absolute URLs (tested)

The Location response header tells the client where to go next (on a 3xx redirect) or where a new resource lives (on 201 Created). A relative value is allowed and works: we sent seven kinds of relative Location on all five redirect codes and Chromium, curl and Node.js fetch all ended at the same URL. The differences that bite are elsewhere: method changes, 201, and redirect: 'manual'.

1. Relative Location values: how they resolve

The request URL was http://localhost:8981/a/b/start?.... Each Location value resolves against that URL like a link in an HTML page at the same address. Results were identical for 301, 302, 303, 307 and 308, and identical in all three clients:

So "relative Location does not work" is almost never the client. The usual bugs are a missing leading slash (next from /a/b/start lands on /a/b/next, not /next), a // prefix that turns your path into a host name, or a proxy in front of the app that rewrites the host or scheme. Absolute URLs avoid the first two, but then the app must know its public scheme and host. Send percent-encoded values yourself rather than relying on clients to clean up spaces and non-ASCII: we saw them cope, but the header is meant to carry an encoded URI.

Without -L curl just prints the raw value, which is the quickest check:

$ curl -si 'http://localhost:8981/a/b/start?code=302&to=next' | head -2
HTTP/1.1 302 Found
Location: next

2. Fragments

• Location: /next#f: Chromium ended at /next#f; curl reported /next#f as the effective URL; Node fetch's res.url was /next (fragment dropped). None of them sent the fragment to the server.
• Fragment inheritance: in Chromium, opening start?...#orig that redirects to /next ended at /next#orig. If the Location has its own fragment (/next#new) that one wins.

3. Which method arrives after the redirect

We sent POST with body a=1 and logged what reached /next:

Use 303 after a successful form POST (post/redirect/get), and 307/308 when the method and body must be kept, for example when moving an API endpoint. With curl, -X POST forces the method name on every hop but the body is still dropped on 301-303; use --post301 --post302 --post303 instead, which kept both POST and a=1 in our test.

4. Location on 201 Created (and 200) is not followed

With Location: /next on a 200, 201 or 202, no client moved: Chromium page navigation stayed on the original URL, fetch() in Chromium and Node returned the 201 itself, and curl -L stopped at 201. On a 204 navigation Chromium aborted (net::ERR_ABORTED) and stayed on the previous page. For a 201, Location is information for the client: the URL of the new resource. Read it and resolve it yourself:

const res = await fetch('/api/items', { method: 'POST', body });
if (res.status === 201) {
  const loc = res.headers.get('location');      // "/next": the raw, possibly relative value
  const url = new URL(loc, res.url).href;        // resolve against the response URL
}

In the browser, a cross-origin API must list it in Access-Control-Expose-Headers: Location, or headers.get('location') returns null (our test server exposed it).

5. Reading Location of a redirect from JavaScript

Page JavaScript cannot see where a redirect points, even same-origin and even with Access-Control-Expose-Headers: Location. If the frontend needs the target, have the API return 200 or 201 with the URL in the body or in a non-redirect Location. On the server (Node), redirect: 'manual' does give you the status and raw header. To see where any URL redirects without code, open it with the HTTP headers checker; for multi-hop chains see how to check a redirect chain, and for PHP's header('Location: ...') pitfalls see PHP header Location redirect not working.

Written with AI assistance. Measured on 2026-10-02 with Node.js 24.21.0 (plain http.createServer on localhost:8981-8982, built-in fetch as the client too), curl 8.14.1 (-L) and headless Chromium 153.0.8010.12 (Playwright). The server answered /a/b/start with 301, 302, 303, 307 or 308 and a chosen Location value; we recorded the final URL and the method and body each client arrived with. PlainHeaders is our extension; Node.js, curl and Chromium are free.