url.domainToASCII inconsistent with WHATWG spec?

[armanbilge]

Version

v17.3.0

Platform

Darwin new-host-3.home 20.6.0 Darwin Kernel Version 20.6.0: Tue Oct 12 18:33:42 PDT 2021; root:xnu-7195.141.8~1/RELEASE_X86_64 x86_64

Subsystem

No response

What steps will reproduce the bug?

url.domainToASCII('42')

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

My expected output is '42'.

This is based on my understanding of the WHATWG spec: https://url.spec.whatwg.org/#idna

Which in particular says:

If beStrict is false, domain is an ASCII string, and strictly splitting domain on U+002E (.) does not produce any item that starts with "xn--", this step is equivalent to ASCII lowercasing domain.

What do you see instead?

'0.0.0.42'

Additional information

I suspect url.domainToUnicode has the same problem.

[MoonBall]

@armanbilge Node.js try to resovle the single number to a ipv4 address by the code. So input '42' is equivalent to input '0.0.0.42'.

I think this is a feature, not a bug. Since '42' is not a valid domain, but it will be valid if it represents a ipv4 address number.

Another tip: Node.js's url.domainToASCII(domain) maybe not conform to url spec. From Node.js's document, the url spec is not mentioned here.

Returns the Punycode ASCII serialization of the domain.

[armanbilge]

@MoonBall thanks for looking into this.

I think this is a feature, not a bug. Since '42' is not a valid domain, but it will be valid if it represents a ipv4 address number.

That may very well be the case, but the docs currently say:

Returns the Punycode ASCII serialization of the domain. If domain is an invalid domain, the empty string is returned.

https://nodejs.org/dist/latest/docs/api/url.html#urldomaintoasciidomain

Furthermore, this behavior is inconsistent with the spec and many (all?) other implementations of domainToASCII in other programming languages. So at the very least, this is extremely surprising and should be documented as such.

Another tip: Node.js's url.domainToASCII(domain) maybe not conform to url spec. From Node.js's document, the url spec is not mentioned here.

I may have misunderstood, but the table-of-contents appears to list url.domainToASCII methods under the "The WHATWG URL API" section in the docs: https://nodejs.org/dist/latest/docs/api/url.html

For the record, punycode.toASCII('42') will return '42'.

[MoonBall]

I am wrong. The URL module conforms to url spec of whatwg.

I may have misunderstood, but the table-of-contents appears to list url.domainToASCII methods under the "The WHATWG URL API" section in the docs: https://nodejs.org/dist/latest/docs/api/url.html

I find that Chrome also treat a number to a valid ipv4 address. Maybe it's a conventional implement, even though the ipv4 spec doesn't include it.

[MoonBall]

Need a more professional guy to answer if '40' should be a valid ipv4 address. 😊

[armanbilge]

Right, but in those screenshots you are invoking the new URL constructor. Apologies if I'm missing something, but how does this relate to domainToASCII?

[MoonBall]

Right, but in those screenshots you are invoking the new URL constructor. Apologies if I'm missing something, but how does this relate to domainToASCII?

Since I don't find domainToASCII in Chrome, but new URL will execute algorithm of domain to ascii .

[armanbilge]

So I looked into this a bit more. Actually, it seems these methods were removed from the WHATWG spec in:

• Remove URL.domainToASCII and URL.domainToUnicode whatwg/url#63

It's very possible that Node.js is the only "real" implementation of these methods in the wild :) but this means it is difficult/impossible to find another WHATWG implementation of these methods to compare to. Also, there's the philosophical question of whether it makes sense to change the implementation in Node.js to correctly adhere to a spec that's been retired/deprecated (assuming that there even is a bug here, which we have yet to establish anyway).

[annevk]

As originally defined these methods would go through https://url.spec.whatwg.org/#concept-host-parser first, which does the number-to-IPv4 conversion. So this seems correct.

[armanbilge]

@annevk thank you for clarifying this, much appreciated.