Unescaped '>' should probably not be allowed in URLs

[bzbarsky]

The standard way, going back to at least the mid-90s, to mark up URLs in text is <url>. This, of course, relies on unescaped > not being allowed in URLs. This is clearly stated, with exactly this rationale, in RFC 1738 section 2.2. The URL standard should have similar provisions.

I don't know what that should mean for URL parsing, but in terms of serialization '>' should always be escaped in URLs, imo.

I just tested browser behavior, and:

• Firefox consistently escapes '>' in path, userinfo, query, fragment. '>' in host or port cause parsing failure.
• Safari escapes '>' in path, userinfo, query. It allows '>' unchanged in host and fragment. '>' in port causes parsing failure.
• Chrome escapes '>' in path, userinfo, query, host. It allows '>' unchanged in fragment. '>' in port causes parsing failure.
• Edge escapes '>' in path and host. It allows '>' unchanged in fragment and query. '>' in port causes parsing failure. Presence of userinfo causes parsing failure no matter what.

Testcase used:

<pre><script>
  var strs = [
    "http://test>test/foo\\bar",
    "http://a>b@test/foo\\bar",
    "http://test/foo\\bar/#a>b",
    "http://test/foo\\bar/?a=c>d",
    "http://test:2>3/foo\\bar",
    "http://test/foo>bar\\baz",
  ];
  for (var str of strs) {
    var a = document.createElement("a");
    a.setAttribute("href", str);
    var href;
    try {
      href = a.href;
    } catch(e) {
      href = "href getter threw";
    }
    var url;
    try {
      url = (new URL(str).href);
    } catch(e) {
      url = "constructor threw";
    }
    document.writeln(str, " -- ", href, " -- ", url);
  }
</script>

with the \\ bits in there a way to tell whether parsing failed in the href case.

[bzbarsky]

Note also that there are various other standards (e.g. the one for the Link HTTP header) that rely on being able to put <> around a URL to delimit it.

[annevk]

Apart from host it seems this is in order: https://jsdom.github.io/whatwg-url/#url=aHR0cHM6Ly9leGFtcGxlLmNvbS88Pj88PiM8Pg==&base=YWJvdXQ6Ymxhbms=. Probably due to #347.

Host is tracked by #458.