-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: document what is a valid URL #18824
Labels
Milestone
Comments
\cc @bradfitz |
What about adding a few examples to url.Parse? |
CL https://golang.org/cl/36124 mentions this issue. |
CL https://golang.org/cl/36127 mentions this issue. |
rsc
referenced
this issue
Feb 17, 2017
RFC 3986 §3.3 disallows relative URL paths in which the first segment contains a colon, presumably to avoid confusion with scheme:foo syntax, which is exactly what happened in #16822. Fixes #16822. Change-Id: Ie4449e1dd21c5e56e3b126e086c3a0b05da7ff24 Reviewed-on: https://go-review.googlesource.com/31582 Reviewed-by: Quentin Smith <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This post on go-nuts is indicative that the url package is very frequently mis-used. Even when I was running go1.8 over Go code inside Google, incorrect usages of
url.Parse
were a frequent source of problems.One very common mistake I see is something like the following:
This is a valid URL, but it does not do what people expect it to do. When printed, it shows:
What the user was expecting was:
Notice that the IP address is part of the Path component and not the Host?
The current behavior is correct because the URL provided is not an absolute URL and therefore must be parsed as a relative URL. However, this behavior is not obvious.
In order to get around this issue, I have seen users do
url.Parse("//192.168.0.1/path/to/endpoint")
to achieve the desired behavior. While this properly parses "192.168.0.1" as the Host and "/path/to/endpoint" as the Path, it is not obvious to users that this is a valid URL. (this format is called the "network-path reference" from RFC 3986, section 4.2)The text was updated successfully, but these errors were encountered: