Also, see https://datatracker.ietf.org/doc/html/rfc2396#section-3 for more details on the scheme + authority.
It all depends on what the URL parse is supposed to return, and based on the return structure - since it has elements like ‘host’ - it is supposed to be decoding a valid http url - using a single slash is not valid. > On Feb 20, 2025, at 11:30 PM, robert engels <reng...@ix.netcom.com> wrote: > > I don’t think it is a valid url according to the rfc > https://datatracker.ietf.org/doc/html/rfc3986#section-3.2 > > An http scheme url requires the //, see > https://datatracker.ietf.org/doc/html/rfc2616#section-3.2.2 > >> On Feb 20, 2025, at 11:18 PM, 'Dan Kortschak' via golang-nuts >> <golang-nuts@googlegroups.com> wrote: >> >> 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. > -- 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/2C4C0A78-9DA2-4283-B3CD-0BBCEDB44133%40ix.netcom.com.
