net/http: client overwrites valid Authorization headers when user included in URL

[sinbad]

In function send() in net/http/client.go:

    if u := req.URL.User; u != nil {
        username := u.Username()
        password, _ := u.Password()
        req.Header.Set("Authorization", "Basic "+basicAuth(username, password))
    }

This means if someone builds a Request which includes the username and password already encoded in the Authorization header, either set directly or via SetBasicAuth(), and the URL happens to include a username (but no password) - which is somewhat common in Git clone URLs for example - the request has its Authorization header re-written and authentication will fail, rather inexplicably for the developer who believes they constructed their request correctly (indeed sending the same thing via curl works). I only figured out why this was by using Wireshark then looking at the Go source!

I think Go should not overwrite the Authorization header if it is already present. I suggest this code should instead be:

    if u := req.URL.User; u != nil && req.Header.Get("Authorization") == "" {
        username := u.Username()
        password, _ := u.Password()
        req.Header.Set("Authorization", "Basic "+basicAuth(username, password))
    }

While you might suggest not using a username and no password in the URL if Authorization is present, these URLs are out there on systems already, and stripping them because of this unintuitive behaviour is the wrong approach.

I would have just submitted a PR if you were using them :)

[gopherbot]

CL https://golang.org/cl/11510 mentions this issue.