Redirects and response control

Location HTTP Header

Provides a URI used to identify a redirect target or the location of a newly created resource.

Applicability

This field applies to HTTP responses.

Syntax

Location: <URI-reference>

Examples

Location: https://www.example.com/new-path
Location: /orders/12345

Common use cases

  • Redirect a client from an obsolete path to the current canonical resource.
  • Identify the resource created by a successful 201 response.

Common mistakes

  • Building a redirect from untrusted input without an allowlist and creating an open redirect.
  • Confusing Location with Content-Location, which identifies the enclosed representation rather than directing navigation.

Security considerations

Validate redirect targets and generated identifiers to prevent phishing, credential leakage, response splitting, and disclosure of internal hosts or object keys.

Detailed guidance

Meaning and behavior

Location contains a URI reference whose meaning depends on the response status. For redirection responses it identifies the target to which the client can navigate, with method handling determined by the particular 3xx status. On a 201 Created response it identifies a specific resource created by the request. The value can be absolute or relative; a relative reference is resolved against the effective request URI according to URI rules.

Location is distinct from Content-Location. Content-Location describes the URI of an enclosed representation and does not automatically redirect a user agent. Redirect statuses also differ: 301 and 308 are permanent signals, 302 and 307 are temporary, and 303 instructs retrieval with GET semantics. Clients, caches, and search engines can retain or interpret these choices differently, so status and target must be designed together.

Implementation notes

Generate targets from trusted route construction rather than concatenating Host, forwarding fields, or arbitrary return URLs. If user-selected destinations are required, parse them and enforce exact allowed schemes, hosts, and paths. Prevent control characters and response splitting. Avoid leaking private service names, signed storage URLs, or predictable identifiers in 201 responses. Test relative resolution, query and fragment handling, proxy host normalization, every redirect status, POST behavior, caches, and loops. Keep authorization on the destination; a redirect does not grant access. For canonical migrations, update internal links and monitor chains rather than leaving multiple hops indefinitely.

Sources