In addition, both "<" and ">" are allowed in host (specifically registered name) when they shouldn't be as per: https://tools.ietf.org/html/rfc3986#section-3.2.2

https://golang.org/src/net/url/url.go?s=2590:2650#L100

This should pct-encode the ">", but doesn't:
https://play.golang.org/p/aVV6I6q-mPV

@zombiezen I wrote a test with your expected result, and I got it passing by removing a check here:
https://github.com/golang/go/blob/master/src/net/url/url.go#L221-L223
Those lines appear to explicitly exclude ASCII (but for the %25) from escaping on parse

The note on the if branch mentions page 21 of that same RFC that you've linked: https://github.com/golang/go/blob/master/src/net/url/url.go#L215-L220

I think this is the relevant bit:

The reg-name syntax allows percent-encoded octets in order to
represent non-ASCII registered names in a uniform way that is
independent of the underlying name resolution technology. Non-ASCII
characters must first be encoded according to UTF-8 [STD63], and then
each octet of the corresponding UTF-8 sequence must be percent-
encoded to be represented as URI characters.

Also, I can see that the mention about RFC implementation by the package has been "relaxed" a while ago: https://go-review.googlesource.com/c/go/+/22859/
And here: #16127 (comment)

Not sure how to interpret the RFC, but happy to hear your thoughts.

Also worth noticing that some tests are actually checking the opposite behaviour:
https://github.com/golang/go/blob/master/src/net/url/url_test.go#L1432

@bradfitz, any thoughts on this issue? I remember there being some subtleties about what sort of changes we want to permit around net/url.

Given that we String-ify such Hosts, I'm not opposed to trying to Parse them too. We'll see what breaks. But please send a change soon, as the freeze is coming, and net/url changes are notorious for breaking things & getting reverted.

What's not entirely clear to me is:
The RFC says:

The reg-name syntax allows percent-encoded octets in order to
represent non-ASCII registered names in a uniform way that is
independent of the underlying name resolution technology.

The example of / is an "ASCII" character after all. 🤔

I've made a change, and I'll open a CL, but there were tests explicitly asserting the opposite of what this issue says, see:

• https://github.com/golang/go/blob/master/src/net/url/url_test.go#L1432
• https://github.com/golang/go/blob/master/src/net/url/url_test.go#L1430

Also the current comment on the if statement mentions:

// Per https://tools.ietf.org/html/rfc3986#page-21
// in the host component %-encoding can only be used
// for non-ASCII bytes.
// But https://tools.ietf.org/html/rfc6874#section-2
// introduces %25 being allowed to escape a percent sign
// in IPv6 scoped-address literals. Yay.

Have a look at the changes.

Change https://golang.org/cl/172157 mentions this issue: net/url: Parse allow ASCII percent-encoded chars in host

@bcmills @zombiezen RFC3986 says %-encoding is allowed in reg-name for only non-ASCII characters; / is an ASCII character.

If I'm interpreting this correctly, Parse should not permit %-encoded ASCII characters.

Should this issue be closed? If no, I would like to start working on a patch improving upon @thoeni's CL 172157 .

In that case the encoding "/" as %2F is wrong? What code is responsible for that? (See testcase in opening msg)