@bradfitz - any reason we are not escaping the query string ?

I forget. But every time we touch this package we break tons of people, so might be best alone or documented.

I invite people to read RFCs for guidance, compare other implementations, and explore what would break if we changed this.

Simply applying u.Query().Encode() breaks a lot, even trivial round trips due to sorting of keys and always writing = (e.g. /?foo=bar&baz goes to /?baz=&foo=bar).

Decided to try doing something similar to url.ParseQuery except for simply writing keys and values instead of storing them in a map for the sake of preserving keys' order. At first glance it doesn't seem to be breaking a lot.

In all cases, though, outputting magnet links will suffer from fixing this issue (see #20054).

Change https://golang.org/cl/168559 mentions this issue: net/url: make URL.String parse and escape query

Currently trying to find what this CL above breaks out in the wild. So far the only thing that bothers me is checking for u.User == nil && u.Host == "" && u.Path == "" in order not to break magnet links.

Question remains whether this is a valid approach, though. I wasn't able to find any URI scheme other than magnet that looks like opaque URIs but not quite and uses query values instead. If that's the case, shouldn't we just do if u.Scheme == "magnet"? What's worse with magnet links is that people seem to validate and convert them with regular expressions, instead of parsing the URL and extracting query values from there.

Also related #22907.

fwiw, I believe the correct way of encoding the domain part wold be ...
https://xn--babb6r0eedb.xn--obae9fb/
If at all. And do we want that for String()? I want that for DNS resolving, yes but not for reading the domain.

After spending about a month on testing it against different projects, I think that uploaded CL fixes this fairly well. I guess leaving it for a while on tip would expose real-world breakages.

As for what others do, it's complicated:

• Java's java.net.URL doesn't do any escaping.
• Python's urllib.parse.urlparse doesn't do any escaping (has methods for doing that).
• Ruby's URI accepts only ASCII symbols.
• Rust's url::Url escapes everything by default (playground).

@bradfitz you've mentioned that most of the changes in net/url break somebody. I've spent some fair amount to time testing proposed change against different projects, but that's obviously not enough.

Now that 1.13 is released does it make sense to land CL168559 on master in order to have enough time to test and realize whether this actually breaks somebody and if so revert it before 1.14?

I occasionally rebase this CL on top of releases in order to use it. Since 1.16 my change breaks a test regarding IA5String encoding: 1eeaff7

--- FAIL: TestIA5SANEnforcement (0.00s)
    --- FAIL: TestIA5SANEnforcement/marshal:_unicode_uniformResourceIdentifier (0.00s)
        x509_test.go:2783: expected CreateCertificate to fail with template: &{[] [] [] [] [] [] 0 0 <nil> 0 0   0001-01-01 00:00:00 +0000 UTC 0001-01-01 00:00:00 +0000 UTC 0 [] [] [] [] [] false false 0 false [] [] [] [] [] [] [] [https://example.com/?%E2%88%9E] false [] [] [] [] [] [] [] [] [] []}

@rolandshoemaker could you advise whether it makes sense NOT to expect error anymore once the whole URL is properly escaped? Wouldn't quoting actually fix those rare badly encoded names you mention in the commit message?
Probably @FiloSottile might want to take a look as well, given that he reviewed the commit above.

I think removing the test case should be fine, yet it feels terribly wrong to just remove a test case in a crypto/* package and declare it win 😁