RFC 7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Note: This RFC has been obsoleted by RFC 9110

Errata ID: 6354
Status: Rejected
Type: Technical
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.

Notes:

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.
--VERIFIER NOTES--
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/>.

Report New Errata