Weird constructor results (for IPv6, non-ports)

[annevk]

Unless I'm missing something, the constructor should probably accept valid URLs.

It seems to throw for http://[::1]/, but not http://a:a/.

[wanderview]

You can construct this kind of hostname pattern with the dictionary constructor:

new URLPattern({ hostname: '[\\:\\:1]' });

You can also get the constructor string to work if you wrap the hostname in a grouping. Either of these work:

new URLPattern("http://{[\\:\\:1]}/");
new URLPattern("http://(\\[::1\\])/");

As you can see, though, ipv6 syntax is going to need heavy escaping since it uses : which is a pattern special char and [] which are regexp special chars.

As discussed in the non-normative note under constructor string parsing the string constructor is meant as a convenience for common URLs, but is not expected to cover every case. If developers run into a situation where the constructor string does not work for their kind of URL they can fall back to the dictionary constructor.

In this case I think if we get lots of developer feedback that ipv6 is needed in the constructor string we could add it later since the current behavior throws. I'm a bit hesitant to add this complexity without that feedback, though.

[wanderview]

That being said, I'll still investigate this a bit more to see if it can be added without too much difficulty.

[wanderview]

By the way http://a:a does not throw because :a is valid pattern syntax for a named group. So this has a hostname pattern of a:a. Its not interpreted as a port. If you want to make it be interpreted as a port you have to write http://a\\:a which does indeed throw.

Note, you don't need to escape the colon for a valid port like http://a:8080 because :8080 is not valid syntax for a named group (first char can't be a digit).

Again, the non-normative note under constructor string parsing may help with understanding these differences.

[wanderview]

An easier example of a URL that requires escaping to be passed to URLPattern is data:foo. You must do new URLPattern("data\\:foo"). We have to do it this way or it would be impossible to represent a relative pathname like user:id.

[wanderview]

Anne, did my explanation about how the constructor string works clear this issue up at all? Should I close it or would you like to discuss further?

To repeat/clarify my posts above, the constructor string parser tries to accept unmodified URLs, but in cases where we can't distinguish between pattern syntax and URL syntax we need escape chars. The IPv6 issue was a deficiency in the parser that we're fixing.

[annevk]

Yeah, thanks! I think this can be closed.