Dec 15, 2013

How Furl handles userinfo part of URI

I didn't know until several days ago that Furl handles userinfo part of URI. Actually I didn't really get to care about it because a) I used Data::Validate::URI for URI validation and it didn't allow username:password@sample.com format so userinfo couldn't be any part of my product, and b) RFC3986 clearly discouraged the use of username:password in URI string.
7.5. Sensitive Information
URI producers should not provide a URI that contains a username or password that is intended to be secret. URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies). A password appearing within the userinfo component is deprecated and should be considered an error (or simply ignored) except in those rare cases where the 'password' parameter is intended to be public. RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax
I was reading Furl::HTTP's code and accidentally found its implementation. It parses input URI in _parse_url() and if username is present, it properly sets username:password combo in Authorization header.
if (defined $username) {
     _requires('MIME/Base64.pm', 'Basic auth');
     push @headers, 'Authorization', 'Basic ' . MIME::Base64::encode_base64("${username}:${password}");
}
Then I became curious if LWP::UserAgent allows the use of userinfo, and I found that it also allows the use of it, too.