| 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:
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.
Absolute URLs are URLs that start with a scheme (e.g., http:, https:, telnet:, mailto:) 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 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:
HTTP/1.1 302 Found
Location: /articles/
The URL of the location is expanded by the client to https://www.example.com/articles/.
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:
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.