On Thu, 2025-02-20 at 20:05 +0800, Lin Lin wrote:
> Hi, gophers
>
> I ran into a URL parsing issue and am a little confused about the
> url.Parse behavior.The doc says:
>
> // Parse parses a raw url into a [URL] structure.
> //
> // The url may be relative (a path, without a host) or absolute
> // (starting with a scheme). Trying to parse a hostname and path
> // without a scheme is invalid but may not necessarily return an
> // error, due to parsing ambiguities.
>
> I.E. url.Parse can return a nil in some situations even with a
> malformed target. The following code confirms that.
>
> package main
>
> import "net/url"
> import "fmt"
>
> func main() {
> u := "http:/127.0.0.1/index.html" // a wrong format
> URL, lacking of a /
> obj, err := url.Parse(u)
>
> fmt.Printf("obj: %#v, error: %v", obj, err)
> }
>
> I think that's a little conflict with Go's convention. If the error
> is nil, one can be sure any returned Object is good. In this case,
> how can the caller trust the result? Or we can improve the doc to
> explain a bit more. I believe most Go developers will not notice that
> pitfall before one step into it. In my experience, I ran into that by
> calling http.NewRequest with a bad URL, the url.Parse is hidden
> inside, which is even less likely to be noticed.
>
> I've seen issues below, they were closed.
>
> https://github.com/golang/go/issues/35245
> https://github.com/golang/go/issues/54689
>
> Maybe we can improve that.
>
> Thanks for your time, best regards.
> Lin Lin
As others have noted, the URL there is valid. If it's not valid for
your use, you can perform additional validation like so
https://go.dev/play/p/v3Wjq6jzuYK
Dan
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/e1f5dffff9984992799b4e01345d1f89d6783ff2.camel%40kortschak.io.
