Comment 1:

I wonder if I really meant http:/// or http:// (three or two slashes).
With three slashes it is clearly net/http's fault - no host at all.
With two slashes it should say tcp Users:443, which I think it would.
So I am assuming this bug is the 3-slash problem, which is not net's.
It might be in url instead of http.

Comment 2:

Labels changed: added size-m.

Comment 3:

Labels changed: added suggested.

Comment 4 by alakriti:

It seems to me the issue here is in net/url.  RFC 3986 Section 3.2.2
(http://tools.ietf.org/html/rfc3986#section-3.2.2) states:
If the URI scheme defines a default for host, then that default applies when the host
subcomponent is undefined or when the registered name is empty (zero length).  For
example, the "file" URI scheme is defined so that no authority, an empty host, and
localhost" all mean the end-user's machine, whereas the "http" scheme considers a
missing authority or empty host invalid.
So if the scheme is http or https and we have 3-slashes, we have a missing host, so we
should be returning an error from url.Parse
I'd be happy to submit a patch if you agree.

Comment 5:

Brad, do you think url.Parse should reject http:///file, or should the http client be in
charge of checking Host != "" before dialing?

Comment 6:

Let's make the HTTP client check that anyway.  I'll defer to others on what is correct
URL-wise.

Comment 7:

This issue was updated by revision f85b94a.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6931052

Comment 8:

Russ, I think this bug is fixed, but maybe you want to do more here.
Leaving for you to close.

Status changed to Fixed.

Comment 9:

Whoops, I closed it on accident anyway.

Comment 10:

lgtm