Location

When a server needs to send clients to a different URL or identify a newly created resource, the Location response header provides the target address.

Table of Contents

Usage

Servers include Location when directing clients to a different URL. The header appears in two contexts: redirect responses and resource creation.

For Redirects, the Location value tells the client where to send the next request. The behavior depends on the status code:

  • 301 Moved Permanently and 308 Permanent Redirect indicate the resource has moved to the new URL for all future requests. A 308 preserves the original HTTP method.
  • 302 Found and 307 Temporary Redirect indicate a temporary move. A 307 preserves the original method, while 302 historically allowed method changes.
  • 303 See Other directs the client to retrieve the result at a different URL using GET, commonly used after a POST submission.

For resource creation, a 201 Created response includes Location pointing to the newly created resource. This gives the client a direct reference without requiring a follow-up search.

The Location value accepts both absolute and relative URLs. Relative URLs are resolved against the request URI.

Note

The Location header and the Content-Location header serve different purposes. Location points to the redirect target or newly created resource. Content-Location identifies the direct URL of the returned representation.

Note

Search engines follow redirects and transfer link equity (ranking value) to the target URL on permanent redirects (301, 308). Temporary redirects (302, 307) do not always pass link equity. Using the correct status code during URL migrations preserves search rankings.

Directives

URL

The value is a single URI reference pointing to the target location.

Location: <url>

The URL is either an absolute URI with scheme and host, or a relative reference resolved against the request URI.

Example

A permanent redirect from an old domain to a new one tells clients to update bookmarks and links. With 301, clients are permitted to change the request method from POST to GET.

HTTP/1.1 301 Moved Permanently
Location: https://new.example.re/products

A 308 permanent redirect preserves the original request method, making the redirect safe for POST and other non-GET requests.

HTTP/1.1 308 Permanent Redirect
Location: https://new.example.re/products

After creating a resource through a POST request, the server returns 201 with the Location of the new resource.

HTTP/1.1 201 Created
Location: /api/orders/7891
Content-Type: application/json

A 303 response after a form submission redirects the client to a results page using GET.

HTTP/1.1 303 See Other
Location: /search/results?q=http+headers

Troubleshooting

Redirect failures often appear as infinite loops, broken URLs, or missing headers in the response.

  1. Redirect loop. The Location header points back to the current URL or to another URL that redirects back, creating an infinite cycle. Browsers stop after a set number of hops and display an ERR_TOO_MANY_REDIRECTS error. Trace the chain with curl -L -v to identify the loop. Common causes include a server rule that redirects HTTP to HTTPS while a load balancer redirects HTTPS back to HTTP, or nginx return 301 rules that match the destination URL. In nginx, use if ($scheme = http) guards narrowly and test with both protocols.

  2. Relative URL not resolved correctly. The Location value accepts relative references, but some older clients and intermediaries expect an absolute URL. A path like /new-page resolves against the request URI. Omitting the leading slash creates a relative path that resolves against the current directory, producing unexpected results. Use absolute URLs with scheme and host to avoid ambiguity.

  3. Missing Location header on 3xx response. A redirect status code without a Location header leaves the client with no destination. Browsers display a blank page or an error. Check the server response with curl -I https://example.re/old-path and confirm the header is present. In Apache, Redirect and RedirectMatch directives always include the header. Custom application code must set the header explicitly.

  4. Protocol mismatch in the redirect target. An HTTP URL in the Location header on an HTTPS site triggers mixed-content warnings or blocks the redirect in strict environments. Ensure the target URL matches the originating protocol or upgrades to HTTPS. In nginx, use return 301 https://$host$request_uri; to maintain the secure scheme.

  5. Fragment not preserved across redirects. The fragment identifier (#section) from the original URL is not forwarded in the Location header. Browsers reattach the original fragment to the redirect target only when the target URL contains no fragment of its own. If the Location value includes a different fragment, the original is lost. Server-side code has no access to fragments since browsers do not send them in requests.

  6. Debugging redirect chains. Run curl -L -v https://example.re/start to follow all redirects and see each hop with status codes and headers. DevTools Network tab also shows the full chain. Filter by document type to isolate redirect responses from subresource requests.

See also

Last updated: April 4, 2026