Host parsing UTF-8 decoding can fail

[achristensen07]

Host parsing step 2 currently reads like this:
"Let domain be the result of UTF-8 decode without BOM on the percent decoding of UTF-8 encode on input."
If the UTF-8 decoding fails, it should explicitly say to return failure. This matches Chrome, Firefox, and WebKit after https://bugs.webkit.org/show_bug.cgi?id=167330

[annevk]

Did you add tests on WPT? Also, from what I can tell the patch you uploaded there you are not returning failure since you still manage to extract a scheme, host, patch, etc. from the URL. Or am I misunderstanding the C++ tests?

[achristensen07]

I didn't add tests on WPT yet, but the two tests from my patch, "http://example.com%A0" and "http://%E2%98%83", would be great to add.
My test format is kind of confusing. The first row with empty values (and the original string for things like the anchor tag that need the original invalid URL) indicates that parsing failed with "http://example.com%A0", which now makes WebKit match Chrome and Firefox. The second row shows WebKit's old behavior, which would just make the A lowercase. Same with "http://%E2%98%83" parsing now to the punycode-encoded Unicode snowman, "xn--n3h", where old WebKit's behavior would just leave it as "%e2%98%83"

[annevk]

Thanks. So we should use https://encoding.spec.whatwg.org/#utf-8-decode-without-bom-or-fail instead and propagate the failure. That should be a rather trivial fix.

[annevk]

(If you could reply to the other URL issues before you go to sleep that would be great, but I can understand if you want to wait until tomorrow.)