Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/url: inconsistent Parse error with missing port #12200

Closed
mpl opened this issue Aug 19, 2015 · 8 comments
Closed

net/url: inconsistent Parse error with missing port #12200

mpl opened this issue Aug 19, 2015 · 8 comments
Milestone

Comments

@mpl
Copy link
Contributor

mpl commented Aug 19, 2015

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 ianlancetaylor added this to the Go1.6 milestone Aug 19, 2015
@ianlancetaylor
Copy link
Contributor

CC @mikioh

@mikioh
Copy link
Contributor

mikioh commented Aug 20, 2015

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
Copy link
Contributor Author

mpl commented Aug 20, 2015

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
Copy link
Contributor

mikioh commented Aug 20, 2015

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.

mpl added a commit to mpl/perkeep that referenced this issue Sep 25, 2015
url.Parse in Go 1.5 now fails with the scheme://IPv6:/foo form (trailing
colon). But it still works when the hostname is an actual hostname, or
an IPv4, which seems inconsistent.
This CL therefore not only accepts this new failure (which comes with Go
1.5) but also considers any host with a trailing colon as an invalid URL
and refuses to rewrite it.

There probably are other places in Camlistore where we should the same.

See golang/go#12200

Change-Id: Ib9ea95a71013b5b53f2fd99415015ec916bb4d9d
@jessfraz
Copy link
Contributor

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

@rsc
Copy link
Contributor

rsc commented Dec 4, 2015

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
Copy link
Contributor Author

mpl commented Dec 4, 2015

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
Copy link

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

@rsc rsc closed this as completed in a456e35 Dec 5, 2015
@golang golang locked and limited conversation to collaborators Dec 14, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants