The HTTP Location header field is returned in responses from an HTTP server under two circumstances:
- To ask a web browser to load a different web page. 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
- 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.
While the obsolete IETF standard RFC 2616 (HTTP 1.1) requires a complete absolute URI for redirection, the most popular web browsers tolerate the passing of a relative URL as the value for a Location header field. Consequently, the current revision of HTTP/1.1 makes relative URLs conforming.
Absolute URL example
The obsolete IETF standard requires an absolute URI to follow a Location header, which means it must contain a scheme (e.g., http:, https:, telnet:, mailto:) and conforms 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". In the case that there is no absolute path present, it must be given as "/" when used as a request URI for a resource.
GET /index.html HTTP/1.1 Host: www.example.com
HTTP/1.1 302 Found Location: http://www.example.org/index.php
Relative URL example
This example, is incorrect according to the obsolete standard, which specifies the URI returned to be absolute. However, all popular browsers will accept a relative URL, and it is correct according to the current revision of HTTP/1.1.
GET /blog HTTP/1.1 Host: www.example.com
HTTP/1.1 302 Found Location: /blog/
- Richardson, Leonard (2007). RESTful Web Services. Sebastopol: O'Reilly. pp. 228–230. ISBN 978-0-596-52926-0.
- IETF Datatracker for HTTPbis Part2
- RFC 2616 (HTTP 1.1)
- IETF HTTPbis Working Group Ticket 185
- What are the Consequences for using Relative Location Headers?
- RFC 3986
- IANA Uniform Resource Identifer (URI) Schemes
- RFC 7230 Section 2.7 (HTTP URI)
- RFC 2616 Section 14.30 (Location)
- RFC 7231 Section 7.1.2 (Location)