Hubbry Logo
HTTP locationHTTP locationMain
Open search
HTTP location
Community hub
HTTP location
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
HTTP location
HTTP location
HTTP location
View on Wikipedia
from Wikipedia
HTTP
Request methods
Header fields
Response status codes
Security access control methods
Security vulnerabilities

The HTTP Location header field is returned in responses from an HTTP server under two circumstances:

  1. To ask a web browser to load a different web page (URL redirection). In this circumstance, the Location header should be sent with an HTTP status code of 3xx. It is passed as part of the response by a web server when the requested URI has:
    • Moved temporarily;
    • Moved permanently; or
    • Processed a request, e.g. a POSTed form, and is providing the result of that request at a different URI
  2. To provide information about the location of a newly created resource. In this circumstance, the Location header should be sent with an HTTP status code of 201 or 202.[1]

An obsolete version of the HTTP 1.1 specifications (IETF RFC 2616) required a complete absolute URI for redirection.[2] The IETF HTTP working group found that the most popular web browsers tolerate the passing of a relative URL[3] and, consequently, the updated HTTP 1.1 specifications (IETF RFC 7231) relaxed the original constraint, allowing the use of relative URLs in Location headers.[4]

Examples

[edit]

Absolute URL example

[edit]

Absolute URLs are URLs that start with a scheme[5] (e.g., http:, https:, telnet:, mailto:)[6] and conform to scheme-specific syntax and semantics. For example, the HTTP scheme-specific syntax and semantics for HTTP URLs requires a "host" (web server address) and "absolute path", with optional components of "port" and "query".

A client requesting https://www.example.com/index.html using 

GET /index.html HTTP/1.1
Host: www.example.com

may get the server response 

HTTP/1.1 302 Found
Location: https://www.example.org/index.php

Relative URL absolute path example

[edit]

Relative URLs are URLs that do not include a scheme or a host. In order to be understood they must be combined with the URL of the original request.

A client request for https://www.example.com/blog/all may get a server response with a path that is absolute because it starts with a slash:[7] 

HTTP/1.1 302 Found
Location: /articles/

The URL of the location is expanded by the client to https://www.example.com/articles/.[8]

Relative URL relative path example

[edit]

A client request for https://www.example.com/blog/latest may get a server response with a path that is relative because it doesn't start with a slash:[7] 

HTTP/1.1 302 Found
Location: 2020/zoo

The client removes the path segment after the last slash of the original URL and appends the relative path resulting in https://www.example.com/blog/2020/zoo.[9][8]

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

HTTP location

View on Grokipedia
from Grokipedia
The HTTP Location header field is a response header in the Hypertext Transfer Protocol (HTTP) that specifies a URI reference to a associated with the response, primarily used to indicate the location of a newly created or to redirect the recipient to an alternative URI. Its syntax is defined as Location = URI-reference, where the value is a single URI-reference that may be absolute or relative, resolved against the effective request URI if relative. This header derives its specific meaning from the context of the request method and response status code, making it essential for standard HTTP behaviors like relocation and creation notifications. In practice, the Location header is most commonly associated with the 201 Created status code, where it is recommended to identify the primary URI of the resource resulting from a successful creation operation, such as after a POST request that generates a new entity. For redirection purposes, it appears in responses with 3xx status codes (Redirection), including 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, and 308 Permanent Redirect, to specify the target URI for the client or user agent to follow. In these cases, the header guides automatic or manual redirection, with the choice of HTTP method for the subsequent request depending on the original method and the redirection type— for instance, GET is typically used after 303 regardless of the initial method. If the Location URI lacks a fragment identifier, it inherits the one from the original request URI to preserve context. The header's role extends beyond strict redirection; it can also appear in other contexts, such as with the 202 Accepted status code to point to a tracking an asynchronous operation, though this is less standardized. Defined initially in HTTP/1.1 specifications and refined in subsequent updates, the Location header ensures across HTTP versions by focusing on semantic clarity rather than transport details. User agents, including web browsers, have supported it universally since the early 2000s, enabling seamless navigation in web applications and APIs.

Overview

Definition

The Location header is a response header field in the Hypertext Transfer Protocol (HTTP) that specifies a URI reference to identify a specific in relation to the response, serving as an indicator for the target in scenarios such as redirection or resource location. It provides a means for servers to communicate the URI of a to clients, enabling appropriate navigation or reference without requiring additional requests in certain contexts. Defined within the semantics of HTTP as per RFC 9110, the Location header is integral to the protocol's response handling, where it is mandatory in specific response contexts to direct client behavior effectively, such as guiding user agents toward a designated . This ensures and standardized interpretation across HTTP implementations, with the header's presence influencing how clients process and act upon server responses. Technically, the Location header is classified as a single-value field, meaning it conveys exactly one URI reference rather than a list, and its value adheres to the URI-reference production rule from RFC 3986, allowing for either an absolute URI or a relative reference that resolves against the effective request URI. This structure supports flexibility in URI specification while maintaining precision in resource identification.

Primary Purposes

The Location header field in HTTP serves primarily to indicate the URI of a to which the client should redirect or reference following a server response. In redirection scenarios, it instructs the , such as a , to retrieve a different , often to handle cases where the requested has been moved, renamed, or temporarily relocated to an alternative endpoint. This mechanism enables seamless navigation without requiring the client to know the new location in advance. Another key purpose of the Location header is to identify the URI of a newly created in response to successful creation requests, such as those using POST or PUT methods. Upon successful creation, the server includes the Location header to provide the canonical URI for the new , allowing the client to immediately access, , or further interact with it. This facilitates resource management in web applications and APIs by establishing a persistent identifier for the created entity. Unlike the Content-Location header, which specifies the URI of the specific representation of content included in the response body (e.g., for negotiation), the Location header exclusively points to the target URI for redirection or the primary URI of a newly created . This distinction ensures that Location focuses on navigational or identificatory intent rather than describing the content's origin or . User agents are expected to resolve the URI provided in the Location header relative to the original request URI if it is relative, and to follow it automatically in appropriate contexts, thereby maintaining the flow of the HTTP interaction without user intervention. This behavior promotes efficient resource location and retrieval in distributed systems.

Syntax and Format

Header Structure

The Location header field in HTTP provides a means to specify a URI reference associated with the response, typically indicating the location of a redirected or newly created resource. According to RFC 9110, its syntax is defined as Location = URI-reference, where the value adheres to the Augmented Backus-Naur Form (ABNF) notation and represents a single URI reference as specified in RFC 3986. This allows for absolute URIs, relative references, or URI references including fragments, enabling flexible indication of resource locations without mandating full absolute paths in every case. In HTTP message format, the header appears as a standard response header field line, structured as Location: <URI-reference>, where the field name "" is case-insensitive per HTTP conventions in RFC 9110. Leading and trailing whitespace around the field value is typically ignored or trimmed during parsing, though the value itself should not include unencoded control characters to maintain compliance. Servers generate this header in responses where redirection or resource creation semantics apply, ensuring the value is a well-formed URI reference to avoid issues. A key constraint is that the Location value must constitute a valid URI-reference; malformed or invalid values can result in clients ignoring the header, issuing errors, or failing to process the intended redirection or location indication, as clients are not obligated to handle non-conforming URIs. Regarding encoding, URI components within the value follow the percent-encoding rules outlined in RFC 3986 for representing special or reserved characters, such as spaces (encoded as %20) or non-ASCII characters, to ensure safe transmission over HTTP. This encoding preserves the integrity of the reference while allowing relative forms that resolve against the request's effective URI when necessary.

URI Types and Resolution

The Location header field in HTTP accepts a URI reference, which may be either an absolute URI or a relative reference. An absolute URI provides the complete resource identifier, including the scheme (e.g., https), authority (host and port), and path (e.g., https://example.com/path), enabling resolution without additional context. This form ensures unambiguous targeting of the resource, as defined in the generic URI syntax. Relative references in the Location header take two primary forms: path-relative or absolute-path. A path-relative reference consists of path segments without a leading slash (e.g., newpath or subdir/newpath), while an absolute-path reference begins with a slash (e.g., /newpath). These are not standalone and require resolution against a base URI. Per the HTTP semantics, relative references are resolved relative to the target URI of the original request, rather than any URI associated with the response itself. Resolution follows the algorithm in URI generic syntax, where the base URI (the request's target URI) supplies missing components like scheme and . For an absolute-path relative reference, the path replaces the base path entirely while inheriting the scheme and (e.g., /newpath appended to the host from the base). Path-relative references merge with the base path by appending segments after removing the last base segment (e.g., newpath added to the end of the base path). Dot-segments such as ../ navigate upward in the directory hierarchy during normalization, effectively removing preceding path segments (e.g., ../ ascends one level). The resulting URI undergoes dot-segment removal to produce a normalized absolute form. When processing redirects via the Location header, clients normalize the resolved URI and follow the chain, using the original request URI as the base for each step. Browsers and user agents typically limit redirect chains to prevent loops, with a common recommendation of no more than 5 hops, though implementations often allow up to 30. This resolution ensures consistent resource targeting across HTTP responses.

Usage in Responses

With Redirection Status Codes

The Location header is mandatory in HTTP responses using the 3xx-series redirection status codes 301 (Moved Permanently), 302 (Found), 303 (See Other), 307 (Temporary Redirect), and 308 (Permanent Redirect), where it specifies the URI of the new or alternative that the client should access to fulfill the original request. These codes signal to the client that further action is required, with the Location header providing the target URI to enable seamless relocation, either temporarily or permanently. Client behavior upon receiving a 3xx response with Location varies by the original request method and the specific status code. For safe methods such as GET and HEAD, clients SHOULD automatically follow the redirect to the URI in , preserving the method unless the code specifies otherwise (e.g., 303 mandates conversion to GET). For 307 and 308, if redirection occurs, the original method and request body (if present) must be preserved. In contrast, for unsafe methods like POST, clients SHOULD NOT automatically redirect without user confirmation or explicit configuration, to prevent unintended state changes; if redirection occurs, 307 and 308 require preserving the method and body, while 303 always converts to GET without reusing the body. An exception applies to the 304 (Not Modified) status code, which does not use the Location header; instead, it instructs the client to reuse its cached representation of the original request URI without any redirection. To prevent infinite loops in redirect chains, clients SHOULD detect and intervene in cyclical redirections, typically by tracking the sequence of URIs followed and imposing implementation-specific limits on the number of redirects (e.g., via hop counts).

With Creation Status Codes

The Location header plays a crucial role in HTTP responses indicating successful creation, particularly with status codes that affirm the establishment of new resources on the server. In a 201 (Created) response, the server SHOULD include the header to specify the URI of the primary created by the request, enabling clients to reference and interact with it directly. This usage commonly arises from POST requests that generate new resources or PUT requests that create them when the target does not previously exist, fulfilling the protocol's semantics for affirmative creation outcomes. For asynchronous processing scenarios, the (Accepted) status code may optionally incorporate the Location header to point to a that tracks the status of the pending operation, such as a queued task or job. When present, this URI allows clients to poll or subscribe to updates on the request's progress without assuming immediate completion, though its inclusion depends on whether the server provides such a monitoring endpoint. Best practices for implementing the Location header in these contexts emphasize using a , absolute URI that is immediately accessible to clients, avoiding relative references unless resolved against the request's effective URI. This approach aligns with RESTful API design principles, where the header facilitates retrieval via subsequent GET requests, promoting stateless interactions and efficient discovery of newly created entities. Clients are expected to treat the provided URI as the definitive identifier for the new , using it to access metadata, content, or perform further operations without needing additional queries to locate it.

Examples

Absolute URI Example

In a typical redirection scenario, a client issues a GET request to the resource at /old on a server. The server responds with a 301 Moved Permanently status code, indicating that the requested resource has been permanently relocated, and includes an absolute URI in the header to specify the new target. This setup ensures the client can immediately follow the redirect without needing to resolve any relative references against the original request's base URI. A full example of such a response header follows:

HTTP/1.1 301 Moved Permanently Location: [https](/page/HTTPS)://[example.com](/page/Example.com)/newpage.[html](/page/HTML)

HTTP/1.1 301 Moved Permanently Location: [https](/page/HTTPS)://[example.com](/page/Example.com)/newpage.[html](/page/HTML)

Here, the absolute URI https://example.com/newpage.html fully specifies the scheme, , and path, allowing the client to directly access the new . Upon receiving this response, the client resolves and issues a subsequent request to the absolute URI provided, operating independently of the original request's base (such as the host or scheme from which /old was requested). This direct resolution promotes reliability in redirection, as the target is unambiguous and self-contained. Absolute URIs in the Location header are particularly ideal for scenarios involving cross-domain redirects or changes in protocol scheme, such as migrating from HTTP to , where preserving the exact target details is essential to avoid resolution errors or security mismatches.

Relative URI Example

In HTTP responses, the Location header can employ relative URI references to indicate a redirection target, which are resolved by the client relative to the effective request URI as defined in RFC 3986. Consider a client requesting the resource at https://example.com/blog/post1. The server might respond with a 302 Found status code and a Location header containing a relative URI such as /newpost, an absolute-path reference that points to a new location within the same . The response header would appear as follows:

HTTP/1.1 302 Found Location: /newpost

HTTP/1.1 302 Found Location: /newpost

Upon receiving this, the client resolves /newpost against the original request URI, resulting in the absolute URI https://example.com/newpost. Relative URIs can also use path-relative forms, such as ../category, to navigate up the directory hierarchy. For the same request to https://example.com/blog/post1, the Location header ../category resolves by removing the post1 segment (due to ..), leaving /blog/, then appending category, yielding https://example.com/blog/category. This approach with relative URIs in the Location header reduces redundancy by omitting the scheme and authority for same-origin redirects, thereby shortening the header value and simplifying server configuration, while user agents handle the normalization to absolute form transparently.

Creation URI Example

The Location header is commonly used with the 201 Created status code to indicate the URI of a newly created resource. For instance, a client sends a POST request to https://example.com/users to create a new user. The server processes the request, creates the resource, and responds with a 201 status and an absolute URI in the Location header pointing to the new . A full example of such a response header follows:

HTTP/1.1 201 Created Location: https://example.com/users/123

HTTP/1.1 201 Created Location: https://example.com/users/123

Here, the absolute URI https://example.com/users/123 identifies the primary URI of the created user resource. The client can then use this URI for further operations, such as retrieving the resource details. Relative URIs can also be used in this context, resolved against the request's target URI.

Standards and Evolution

Key RFC Specifications

The Location header field in HTTP was initially defined in RFC 2616, published in June 1999 as a Standards Track document that specified HTTP/1.1 semantics. This RFC established the header as a response field used to redirect recipients to a location other than the request URI, particularly in 201 (Created) responses to identify new resources and in 3xx redirection status codes such as 301 (Moved Permanently) and 302 (Found). It mandated that the Location value consist of a single absolute URI to ensure clients could independently resolve the target without context dependency, with syntax defined as Location = "Location" ":" absoluteURI. RFC 2616 was later obsoleted by the HTTP/1.1 specification updates in 2014. RFC 7231, published in June 2014 as part of the revised HTTP/1.1 core semantics and content on the Standards Track, refined the Location header's definition to enhance flexibility. It describes the header as a means to refer to a specific resource in relation to the response, used in 201 responses to denote the primary created resource and in 3xx responses to indicate the redirection target. Unlike its predecessor, RFC 7231 permits URI references, including relative forms resolved against the effective request URI, with syntax Location = URI-reference. This adjustment supports fragments and relative paths while maintaining interoperability for absolute URIs. The syntax for URIs in the Location header relies on RFC 3986, published in January 2005 as a Standards Track document defining the generic URI syntax. This RFC outlines URI components such as scheme, , path, query, and fragment, using ABNF notation like URI-reference = URI / relative-ref to specify absolute URIs and relative references resolvable via a base URI. It provides the foundational rules for parsing and normalizing Location values in HTTP, ensuring consistent resolution across implementations. RFC 9110, published in June 2022 as an Internet Standards Track document on HTTP semantics, consolidates and updates the Location header specifications from prior RFCs including 7231. It reaffirms the header's role in 201 responses for new resource URIs and 3xx responses for redirection targets, retaining the URI-reference syntax while clarifying rules for automatic client redirection based on status codes like 301, 302, and 303. This consolidation separates semantics from transport details, obsoleting RFC 7231 and related documents to streamline HTTP evolution.

Changes Across HTTP Versions

In HTTP/1.0, as defined in RFC 1945 published in 1996, the Location header provided informal support for redirects, primarily in conjunction with status codes 301 (Moved Permanently) and 302 (Moved Temporarily), where it was required to specify the new URI for the . The header's value was optional in broader contexts but consisted exclusively of a single absolute URI when used, ensuring unambiguous redirection without reliance on relative paths. With the advancement to HTTP/1.1 in RFC 2616 from 1999, the Location header became more formalized, mandating the use of absolute URIs exclusively, as relative URIs were explicitly not permitted to maintain across clients and servers. This version introduced specific requirements tying the header to additional status codes, including 201 (Created) for identifying new resources, and redirection codes such as 303 (See Other), 305 (Use Proxy), and 307 (Temporary Redirect), enhancing its role in precise resource location and method preservation during redirects. The 2014 update to HTTP/1.1 semantics in RFC 7231 relaxed the URI requirement to allow URI-references, which encompass both absolute URIs and relative references resolvable against the effective request URI, aligning the specification with longstanding browser implementations that already tolerated relatives. This change also incorporated guidance on loop prevention, advising clients to detect and avoid cyclical redirections by tracking redirect chains. The header's usage with status codes like 201 and various 3xx redirects remained consistent, but the flexibility in URI form improved practical deployment. In and subsequent versions, as outlined in RFC 9113 from 2022, there were no structural modifications to the header's semantics, preserving compatibility with prior HTTP/1.1 definitions. However, the protocol's binary framing and HPACK header compression mechanism enhanced transmission efficiency for headers like , reducing overhead in multiplexed streams without altering their interpretation. These evolutions, particularly the shift to permitting relative URIs in modern HTTP/1.1, have reduced server-side by avoiding redundant scheme and components, while maintaining through support for absolute forms to accommodate legacy clients.

References

  1. https://www.rfc-editor.org/rfc/rfc9110.html#section-10.2.2
  2. https://www.rfc-editor.org/rfc/rfc9110.html#status.201
  3. https://www.rfc-editor.org/rfc/rfc9110.html#status.3xx
  4. https://httpwg.org/specs/rfc9110.html#field.location
  5. https://www.rfc-editor.org/rfc/rfc9110.html#section-8.7
  6. https://datatracker.ietf.org/doc/html/rfc9110#section-10.2.2
  7. https://datatracker.ietf.org/doc/html/rfc3986
  8. https://datatracker.ietf.org/doc/html/rfc9110#section-5.1
  9. https://datatracker.ietf.org/doc/html/rfc3986#section-2.1
  10. https://www.rfc-editor.org/rfc/rfc3986.html#section-3
  11. https://www.rfc-editor.org/rfc/rfc3986.html#section-5
  12. https://www.rfc-editor.org/rfc/rfc3986.html#section-5.2
  13. https://httpwg.org/specs/rfc9110.html#status.3xx
  14. https://httpwg.org/specs/rfc9110.html#status.301
  15. https://httpwg.org/specs/rfc9110.html#status.302
  16. https://httpwg.org/specs/rfc9110.html#status.303
  17. https://httpwg.org/specs/rfc9110.html#status.307
  18. https://httpwg.org/specs/rfc9110.html#status.308
  19. https://httpwg.org/specs/rfc9110.html#safe.methods
  20. https://httpwg.org/specs/rfc9110.html#status.304
  21. https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.3
  22. https://www.rfc-editor.org/rfc/rfc9110.html#status.202
  23. https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design
  24. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/201
  25. https://www.rfc-editor.org/rfc/rfc3986.html#section-4.3
  26. https://www.rfc-editor.org/rfc/rfc3986.html
  27. https://datatracker.ietf.org/doc/html/rfc2616
  28. https://datatracker.ietf.org/doc/html/rfc2616#section-14.30
  29. https://datatracker.ietf.org/doc/html/rfc7231
  30. https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.2
  31. https://datatracker.ietf.org/doc/html/rfc3986#section-3
  32. https://datatracker.ietf.org/doc/html/rfc3986#section-5
  33. https://datatracker.ietf.org/doc/html/rfc9110
  34. https://datatracker.ietf.org/doc/html/rfc9110#section-1.2
  35. https://datatracker.ietf.org/doc/html/rfc1945#section-9.3
  36. https://datatracker.ietf.org/doc/html/rfc1945#section-10.11
  37. https://datatracker.ietf.org/doc/html/rfc2616#section-10.2.2
  38. https://datatracker.ietf.org/doc/html/rfc2616#section-10.3
  39. https://datatracker.ietf.org/doc/html/rfc7231#section-6.4
  40. https://datatracker.ietf.org/doc/html/rfc9113#section-8.1
  41. https://datatracker.ietf.org/doc/html/rfc9113#section-4.3
  42. https://datatracker.ietf.org/doc/html/rfc7231#appendix-B
Add your contribution
Related Hubs
User Avatar
No comments yet.