Parsing the hostname "xn--" returns an empty hostname, but doesn't throw an error when a hostname is required #373
Comments
behnam
added a commit
to behnam/rust-url
that referenced
this issue
Jul 3, 2017
Helps with answering question asked in servo#373
behnam
added a commit
to behnam/rust-url
that referenced
this issue
Jul 3, 2017
Helps with answering question asked in servo#373 The test invariants here are based on and checked against: * Processing Step 4 of UTS#46 (<http://www.unicode.org/reports/tr46/#ProcessingStepPunycode>) * 6.2 Decoding procedure of Punycode RFC. (<https://ietf.org/rfc/rfc3492.txt>)
|
It was URL spec issue. Now fixed in whatwg/url#497 |
|
This should be fixed by 6b05499. |
djc
pushed a commit
that referenced
this issue
Aug 25, 2020
Helps with answering question asked in #373 The test invariants here are based on and checked against: * Processing Step 4 of UTS#46 (<http://www.unicode.org/reports/tr46/#ProcessingStepPunycode>) * 6.2 Decoding procedure of Punycode RFC. (<https://ietf.org/rfc/rfc3492.txt>)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Basically,
assert_eq!(Url::parse("ftp://xn--"), Url::parse("ftp:///"));fails. It seems even though idna parsing produces an empty host, it's still not considered empty and a valid Url is constructed instead of returning an error.Is this the expected behaviour? Or should the empty host check not take into account idna processing.
The text was updated successfully, but these errors were encountered: