You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
u, err:=url.Parse("192.168.0.1/path/to/endpoint")
fmt.Printf("%#v\n", u)
This is a valid URL, but it does not do what people expect it to do. When printed, it shows:
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:
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 <quentin@golang.org>
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: