[Errata Rejected] RFC7231 (6354)

[RFC Errata System <[e-mail]>]

The following errata report has been rejected for RFC7231,
"Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6354

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Peter Sturge <[e-mail]>
Date Reported: 2020-12-10
Rejected by: Barry Leiba (IESG)

Section: 7.1.2.

Original Text
-------------
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"

Corrected Text
--------------
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/>.

--------------------------------------
RFC7231 (draft-ietf-httpbis-p2-semantics-26)
--------------------------------------
Title               : Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Publication Date    : June 2014
Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG