- Nov 2015
-
tools.ietf.org tools.ietf.org
-
The URI generic syntax for authority also includes a deprecated userinfo subcomponent ([RFC3986], Section 3.2.1) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password. A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing attacks.
You know...it didn't have to be this way...
RFC3986 Section 3.2.1 states (emphasis added):
The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource.
Additionally, it clearly states that use of the
:is deprecated.Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password).
Further removal of the use of the
userinfosection in HTTP URIs by this RFC was unnecessary...and now just complicates future use of this space.Were it not for this paragraph in RFC7230, userinfo.me could have been a simple thing...
Quoting the sad bit one more time...
A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a request target or header field value.
Time for a new RFC which updates this one and fixes this error.
Tags
Annotators
URL
-