domainToASCII and domainToUnicode in intl
watilde opened this issue · 2 comments
Currently, we're using uidna_nameToASCII_UTF8 or uidna_nameToUnicodeUTF8 when users call domainToASCII or domainToUnicode with the url modules, but accoding to the specification it should be uidna_IDNToASCII and uidna_IDNToUnicode instead of them.
- https://url.spec.whatwg.org/#idna
- http://www.unicode.org/reports/tr46/#ToASCII
- http://www.unicode.org/reports/tr46/#ToUnicode
- http://icu-project.org/apiref/icu4c/uidna_8h.html#a711fa1d2e6dd25d7368f5b3ea2aaedc6
- http://icu-project.org/apiref/icu4c/uidna_8h.html#acf38e44019d4eb5a7dd903284fdb18e3
Then this test case doesn't work because of it. The inputs will be ., .. and 0..0x300 in this case.
How about adding the following methods into node_i18n to fix this issue?
- binding('intl').IDNToASCII
- binding('intl').IDNToUnicode
This problem is related to nodejs/node#11549.
I think uidna_nameToASCII_UTF8 is suitable: to match VerifyDnsLength = false (that means also to allow empty labels), you can just ignore following errors in pInfo->errors: UIDNA_ERROR_EMPTY_LABEL, UIDNA_ERROR_LABEL_TOO_LONG, UIDNA_ERROR_DOMAIN_NAME_TOO_LONG.
uidna_nameToUnicodeUTF8 is also suitable. You can ignore some errors in pInfo->errors (please recheck which), because URL standard (https://url.spec.whatwg.org/#concept-domain-to-unicode) says:
- Signify validation errors for any returned errors, and then, return result.
AFAIK, idna_IDNToASCII and uidna_IDNToUnicode are deprecated.