HTTP location
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 (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 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. An obsolete version of the HTTP 1.1 specifications (IETF RFC 2616) required a complete absolute URI for redirection. The IETF HTTP working group found that the most popular web browsers tolerate the passing of a relative URL and, consequently, the updated HTTP 1.1 specifications (IETF RFC 7231) relaxed the original constraint, allowing the use of relative URLs in Location headers.
| 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:
- 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
- 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]- ^ Richardson, Leonard (2007). RESTful Web Services. Sebastopol: O'Reilly. pp. 228–230. ISBN 978-0-596-52926-0.
- ^ "Location". Hypertext Transfer Protocol -- HTTP/1.1. IETF. June 1999. sec. 14.30. doi:10.17487/RFC2616. RFC 2616.
- ^ IETF HTTPbis Working Group Ticket 185
- ^ "Location". Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. IETF. June 2014. sec. 7.1.2. doi:10.17487/RFC7231. RFC 7231.
- ^ Uniform Resource Identifier (URI): Generic Syntax. IETF. January 2005. doi:10.17487/RFC3986. RFC 3986.
- ^ "IANA Uniform Resource Identifier (URI) Schemes". Retrieved 2014-11-21.
- ^ a b "Relative Reference". Uniform Resource Identifier (URI): Generic Syntax. IETF. January 2005. sec. 4.2. doi:10.17487/RFC3986. RFC 3986. Retrieved 2020-11-22.
- ^ a b "Normal Examples". Uniform Resource Identifier (URI): Generic Syntax. IETF. January 2005. sec. 5.4.1. doi:10.17487/RFC3986. RFC 3986. Retrieved 2020-11-22.
- ^ "Merge Paths". Uniform Resource Identifier (URI): Generic Syntax. IETF. January 2005. sec. 5.2.3. doi:10.17487/RFC3986. RFC 3986. Retrieved 2020-11-22.