url.parse doesn't decode auth field

[natevw]

Shouldn't the url.parse function decode the auth portion of a URL? I'd have expected the following to be true:

require('url').parse("http//either%2for@example").auth === "either/or"

Another user has also requested this via a comment on the somewhat separate issue #1163: #1163 (comment)

[isaacs]

Would anyone like to do a patch for this?

Should probably do #1163 along with it.

Note that it's also used by http.request now, to set the Authorization header.

[bnoordhuis]

It's possible but is it sensible? foo%3Abar:baz decodes to foo:bar:baz. How does the user extract the username and password from that? bnoordhuis/node@c157b16 for better or worse decodes entities in the auth section.

[natevw]

For Basic Authentication, the username is not allowed to have a colon (http://tools.ietf.org/html/rfc2617#section-2). Furthermore, away from the URL layer (which I would argue is the layer I intend to be at if I am using the results of url.parse) there is no concept of "URL escaping".

[isaacs]

@bnoordhuis bnoordhuis/node@c157b16 looks good to me, but we need a test to make sure that http.get(url.parse('http://user%3Afoo%40:bar@localhost:8000/')) sends authorization: 'Basic dXNlcjpmb29AOmJhcg=='

[isaacs]

Oh, actually, that commit fixes a failure in http:

  if (options.auth && !this.getHeader('Authorization')) {
    //basic auth
    this.setHeader('Authorization', 'Basic ' +
                   new Buffer(options.auth).toString('base64'));
  }

Since the auth section should have any non-urlsafe chars encoded, this bit in http.js is a bug.

[bnoordhuis]

Fixed in 86f4846. HTTP basic auth test updated in f116e17.