net/url: inconsistent Parse error with missing port

[mpl]

go version devel +467a2cb Sun Aug 16 00:29:39 2015 +0000 linux/amd64

http://play.golang.org/p/FkTC5G-xhb

With Go 1.4, this runs without any error.
With the above go version, only the last form ([IPv6]:) fails to parse with the error:
invalid port ":" after host

I would expect either parsing not to fail at all, or to fail for all the URLs without a port after the colon, for consistency.

Is this the desired behaviour ?

[ianlancetaylor]

CC @mikioh

[mikioh]

I'm not sure whether there's a good way to support both RFC 3986 and non-RFC 3986 compliant stuff such as database source names and connection strings. See #12023.

Is this the desired behaviour?

That's a good question, but I have no answer to it for now. Sorry.

[mpl]

Just to be clear, my point is not that "http://example.com:/" should be supported, even though it was supported so far in Go 1.4 , and even though section 6.2.3. seems to imply it is a compliant case.

My point is: if it is decided that the "http://example.com:/" form is supported for parsing, then all three of:

https://192.168.0.2:/foo
https://2b01:e34:ef40:7730:8e70:5aff:fefe:edac:/foo
https://[2b01:e34:ef40:7730:8e70:5aff:fefe:edac]:/foo

should probably be supported (as it was the case so far), and not just the two first forms.

Or are you saying that the brackets around the host is exactly what makes that form non-RFC 3986 compliant?

[mikioh]

Or are you saying that the brackets around the host ...

I think of simply accepting https://2b01:e34:ef40:7730:8e70:5aff:fefe:edac:/foo might make people unhappy because the net package and its APIs don't support the host subcomponent of the URL, 2b01:e34:ef40:7730:8e70:5aff:fefe:edac: or 192.168.0.2:, and http.Get(https://2b01:e34:ef40:7730:8e70:5aff:fefe:edac:/foo) returns an error. But I may be wrong.

[jessfraz]

I made this as well see https://play.golang.org/p/qm_YKwrvf3 and moby/moby#15703

[rsc]

For the record, https://2b01:e34:ef40:7730:8e70:5aff:fefe:edac:/foo is NOT a well-formed IPv6 URL. The [ ] around the IPv6 address are not optional. If browsers accept that, consider yourself lucky.

For the most part, net/url makes no attempt to parse the host in the URL. The exception is IPv6 literals, although I am not sure why we bother to check them so carefully. Maybe because they are just one giant exception to all the rules.

In any event, the grammar in https://tools.ietf.org/html/rfc3986#page-22 seems to suggest that port can be an empty string even when a colon is present, so I'll make that change in the IPv6 literal parsing.

[mpl]

well, it's good to know that url.Parse can't be relied upon for checking the host part, thanks. I would think that specific bit should be mentioned somewhere in net/url, but I suppose there's a good reason for it not to be there. Maybe you don't want to commit to that kind of implementation "detail" ?

[gopherbot]

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