net/url: Parse("#foo") should not result in error #4700
Labels
Milestone
Comments
Does http://golang.org/pkg/net/url/#URL.Parse behave differently? |
Seems like no, http://play.golang.org/p/rGuL0uGSZf |
URL.Parse does quite well in the weird examples from RFC 3986, but "" or "#fragment" result in error: http://play.golang.org/p/F0ApSaXniv |
I'd like to implement this in Parse(), so that URL.ResolveReference() could also do this kind of resolution. But I'm afraid that this would be considered an API break, so I implemented it in URL.Parse for now: https://golang.org/cl/7205056 The RFC examples I mentioned in comment 3 are solved in issue #4706. |
|
This issue was closed by revision 82e3ca7. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently url.Parse("#foo") results in an error. It should result in a url.URL with only the Fragment field set, like when you get the RawQuery field set after calling url.Parse("?foo"). URIs that include only a fragment are described by the RFC [1]: The most frequent examples of same-document references are relative references that are empty or include only the number sign ("#") separator followed by a fragment identifier. And of course "#foo" is a valid href value in an HTML document. It gets more curious: "" is also a same-document reference, so should url.Parse("") be allowed? Imagine that for web-scrapping, you define a function that merges the document URL with the href values it finds. This function can't receive *url.URL as argument, because url.Parse("#foo") and url.Parse("") both result in error, despite being meaningful href values. [1] http://tools.ietf.org/html/rfc3986#section-4.4The text was updated successfully, but these errors were encountered: