domainToASCII and domainToUnicode in intl

[watilde]

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.

• web-platform-tests/wpt@3afae94

How about adding the following methods into node_i18n to fix this issue?

• binding('intl').IDNToASCII
• binding('intl').IDNToUnicode

[rmisev]

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:

2. Signify validation errors for any returned errors, and then, return result.

AFAIK, idna_IDNToASCII and uidna_IDNToUnicode are deprecated.

[watilde]

@rmisev You're right! Thank you so much for following up with the great detail.

Closing as resolved.