RFC 7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014Source of RFC: httpbis (app)
Errata ID: 6354
Publication Format(s) : TEXT
Reported By: Peter Sturge
Date Reported: 2020-12-10
Rejected by: Barry Leiba
Date Rejected: 2020-12-15
Section 7.1.2. says:
The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5). For 201 (Created) responses, the Location value refers to the primary resource created by the request. For 3xx (Redirection) responses, the Location value refers to the preferred target resource for automatically redirecting the request. If the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any). For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field: Location: /People.html#tim which suggests that the user agent redirect to "http://www.example.org/People.html#tim"
It should say:
The field value consists of a single URI-reference. Relative forms are not allowed and MUST include the entire redirected URI, even if the base URL part has not changed.
Relative URIs in Location redirect headers should not be allowed.
Allowing relative URIs opens up, at best, inconsistent and poor implementations and interpretations, but more importantly it opens serious security holes.
For example, when the redirect emanates from a URL shortening service (e.g. bitly.com), an attacker can 'chain' multiple relative shortened URIs, effectively obfuscating the final and malicious site.
If security tools attempt to 'rebuild and resolve', this will have an impact on performance, and itself can be exploited by attackers by creating a circular redirect (this can of course be done with full URIs as well, but then a security monitoring tool can more easily detect such a scenario).
Yes, one would expect security tools to only redirect to a small maximum count (say 3), but in a Denial-of-Service attack, many of these can render a security monitoring tool impotent to other attacks happening in parallel.
In addition, unless *all* User-Agents (and there are a lot of them out there) interpret the relative URL absolutely consistently, this can lead to incorrect navigation at best, and such inconsistencies can be easily exploited by attackers at worst.
All in all, at a time when the industry is trying to make internet operations safer and more secure, allowing relative URLs does the opposite, and with little to no gain by allowing.
The text says what the working group intended it to say, and this is not an erratum. What's more, it accurately reflects real-world usage.
The place to discuss changes such as this proposal, to be considered for future updates, is the HTTP working group's mailing list; see <https://datatracker.ietf.org/wg/httpbis/about/>.