Forbidden host code points

[annevk]

In #185 (comment) @achristensen07 complained about the host code point restrictions I was adding for opaque hosts. I figured I'd explain the rules for code point restrictions in hosts in general once here and then we can either decide to agree or fiddle with the specifics.

Currently we have the following restrictions for non-opaque hosts. I listed the justification for each on the right:

• U+0000 (generally problematic)
• U+0009 (stripped when parsing URLs, would create reparsing issues)
• U+000A (stripped when parsing URLs, would create reparsing issues)
• U+000D (stripped when parsing URLs, would create reparsing issues)
• U+0020 (creates copy-and-paste issues, see Consider always escaping U+0020 #125)
• "#" (would create reparsing issues)
• "%" (would create reparsing issues due to host percent-decoding)
• "/" (would create reparsing issues)
• ":" (would create reparsing issues)
• "?" (would create reparsing issues)
• "@" (would create reparsing issues)
• "[" (would create reparsing issues)
• "" (would create reparsing issues)
• "]" (would create reparsing issues)

Now for non-opaque hosts I took this list and removed the code points that were no longer problematic. And those are "%" (opaque hosts have no percent decoding), "[" (no IPv6), "" (no special backslash handling), and "]" (no IPv6).

The reason to be maximally liberal is given in #159 (comment).

@achristensen07 does this help or do you have the same concerns still? And if so, what would you do?

[achristensen07]

This makes sense. I just didn't see a documented reason for the seemingly-arbitrary list, but now it makes sense.

[annevk]

Thank you, that should allow us to close a number of issues this week.

[achristensen07]

For simplicity's sake, since this is so similar to the list of invalid domain characters, it might be nice to keep them the same. That would prevent issues if people switch schemes, etc.

[annevk]

Currently the specification disallows scheme switching for this reason (and also because non-special and special parse so differently), but making them the same seems reasonable nonetheless. I'll refactor the PR so that the list of code points is a reference rather than duplicated.