-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dns.lookup allows a "falsy" hostname, but behaviour is undocumented and appears useless #13119
Comments
I have no clue. It looks like this behavior goes back at least 6 years. My changes look to have just been building on top of the existing quirks. |
@bnoordhuis do you remember the history of any of this? |
There is no real backstory. It was introduced in commit fd3cd75 from 2010 as an optimization of sorts. I think the idea was that an empty hostname string (which is falsy) never returns any results so you might as well take a shortcut. |
@bnoordhuis Is there any reason not to call lookup of an empty string an error? I'm tempted to make everything falsy throw, like
|
No reason except backwards compatibility. :-) |
So what should we do:
|
node is getting stricter about non-sensical arguments over time, I think that's a good trend, and it we should start to reject arguments that are invalid: false, null, undefined, and the empty string, too, IMO. |
Is there someone working to change this behavior ? I would like to contribute to this issue and any leads would be appreciated. |
We can `dns.lookup` a falsy `hostname` like `dns.lookup(false)` for the reason of backwards compatibility long before(see nodejs#13119 for detail). This behavior is undocumented and seems useless in real world apps. We could also make invalid `hostname` throw in the future and the change might be semver-major. Fixes: nodejs#13119
Try to resolve this issue in #23173. Please comment if there are any inappropriate changes. |
We can `dns.lookup` a falsy `hostname` like `dns.lookup(false)` for the reason of backwards compatibility long before(see #13119 for detail). This behavior is undocumented and seems useless in real world apps. We could also make invalid `hostname` throw in the future and the change might be semver-major. Fixes: #13119 PR-URL: #23173 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Denys Otrishko <shishugi@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
I assumed this was a bug, but on looking into it, it seems deliberate:
node/lib/dns.js
Line 132 in 6f21671
@cjihrig you added this, I think, in 5086d6e (missing PR metadata), but it looks like you were cleaning up something from an earlier commit. Any ideas why falsey is allowed?
Its even tested:
node/test/parallel/test-dns-lookup.js
Lines 38 to 48 in 6f21671
My guess was that the intention is that if
hostname
is falsy, there may be enough information inoptions
to return a useful value, in which caseoptions
should be mandatory ifhostname
is missing.Except... I don't see how that can be, it looks to me you will always get no results no matter what flags you put into
options
, and the tests even assert that, so... why is a falsey hostname allowed?The text was updated successfully, but these errors were encountered: