Verify domain is not empty after "domain to ASCII"

[rmisev]

The empty host is not allowed in special non-"file" URLs, but
domain to ASCII result can be the empty string, even if the
input is not empty, for example:

• the input consists entirely of IDNA ignored code points;
• the input is xn--.

The domain to ASCII do not fail when it is called from host parser,
because VerifyDnsLength is false.
So we need additional check after it.

An interesting case is with file URLS, as empty host is allowed. But most
browsers report failure as well. I tested URLs with the U+00AD
percent encoded in host:

URL	Chrome	Firefox	Safari
file://%C2%AD/p	TypeError	file:///p	TypeError
http://%C2%AD/p	TypeError	TypeError	TypeError

Note. To find more IDNA ignored code points refer to IDNA Mapping Table:
https://unicode.org/reports/tr46/#IDNA_Mapping_Table

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • URL: test IDNA ignored code points in host web-platform-tests/wpt#23432
• Implementation bugs are filed:
  • Chrome: …
  • Firefox: …
  • Safari: …

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

See also #438.

I think we should add this check in https://url.spec.whatwg.org/#concept-domain-to-ascii so that a domain also cannot be valid if it ends up empty.

[rmisev]

Hmm, in the valid domain check https://whatpr.org/url/497.html#valid-domain the domain to ASCII is called with beStrict = true, i. e. VerifyDnsLength = true, so will fail anyway on empty result.

[annevk]

Ah fair, I guess I'd still like to include this check there, but I'd be okay with making it conditional upon beStrict. At some point we have to revise the general ToASCII operation and it would be good if all the weirdness was consolidated to make that easier.

[rmisev]

OK, changed.