net/url: Parse+String does not round trip magnet URLs

[rsc]

I received a private email with a report that Go inserts // in magnet URLs.
That appears to mean https://en.wikipedia.org/wiki/Magnet_URI_scheme.
Round-tripping the example from that wikipedia page:

package main

import (
	"fmt"
	"net/url"
)

func main() {
	fmt.Println(url.Parse(`magnet:?xt=urn:btih:c12fe1c06bba254a9dc9f519b335aa7c1367a88a&dn`))
}

prints

magnet://?xt=urn:btih:c12fe1c06bba254a9dc9f519b335aa7c1367a88a&dn <nil>

https://play.golang.org/p/OQKMvDyTD-

It does seem like the leading // should not be there. However, I don't know how much this matters, nor how invasive this would be to fix, nor whether the // insertion is correct for any other schemes (in particular, http and https).

/cc @bradfitz

[bradfitz]

We don't special case mailto: so it'd be nice to not special case magnet:.

But perhaps we could tweak our heuristics for URL.String's Opaque-vs-:// forms.

[rsc]

Hmm, so mailto:rsc?subject=hi round-trips but mailto:?subject=hi turns into mailto://?subject=hi.

[dsnet]

Part of the problem is that we parse the Opaque field out as the empty string. When we try to round trip, we notice that the Opaque field is empty and assume it's a hierarchical URL, which it is not. Perhaps, we should add a ForceOpaque bool field?

[rsc]

I would rather not add a new bool.

If u.User == nil && u.Host=="" && u.Path=="", can we print that part as an empty string instead of as //?

[johnnyluo]

I am interested to work on this one, can someone assign it to me? so other people won't waste time on this

[gopherbot]

CL https://golang.org/cl/49050 mentions this issue.

[odeke-em]

Moving this to Go1.10 as per the CL update and given how deep we are in the freeze Go1.9.

[johnnyluo]

@dsnet @odeke-em could you guys please help to run trybot on CL https://golang.org/cl/49050, the previous trybot failed , however it is nothing to do with my change.

[odeke-em]

Thanks for the ping @johnnyluo, I've ran the trybot.