Home Original page

dns: Use object without protoype for map by benjamingr · Pull Request #5843 · nodejs/node

@benjamingr added dns

Issues and PRs related to the dns subsystem.

semver-major

PRs that contain breaking changes and should be released in the next major version.

labels

Mar 22, 2016

@benjamingr 

Currently we use `{}` for the `lookup` function to find the relevant
resolver to the dns.resolve function. It is preferable to use an
object without a Object.prototype, currently for example you can do
something like:

```js
dns.resolve("google.com", "toString", console.log);
```

And get `[Object undefined]` logged and the callback would never be
called. This is unexpected and strange behavior in my opinion.
In addition, if someone adds a property to `Object.prototype` might
also create unexpected results.

This pull request fixes it, with it an appropriate error is thrown.

@benjamingr benjamingr removed the semver-major

PRs that contain breaking changes and should be released in the next major version.

label

Mar 22, 2016

@benjamingr

jasnell pushed a commit that referenced this pull request

Mar 22, 2016 
Currently we use `{}` for the `lookup` function to find the relevant
resolver to the dns.resolve function. It is preferable to use an
object without a Object.prototype, currently for example you can do
something like:

```js
dns.resolve("google.com", "toString", console.log);
```

And get `[Object undefined]` logged and the callback would never be
called. This is unexpected and strange behavior in my opinion.
In addition, if someone adds a property to `Object.prototype` might
also create unexpected results.

This pull request fixes it, with it an appropriate error is thrown.

PR-URL: #5843
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

evanlucas pushed a commit that referenced this pull request

Mar 30, 2016 
Currently we use `{}` for the `lookup` function to find the relevant
resolver to the dns.resolve function. It is preferable to use an
object without a Object.prototype, currently for example you can do
something like:

```js
dns.resolve("google.com", "toString", console.log);
```

And get `[Object undefined]` logged and the callback would never be
called. This is unexpected and strange behavior in my opinion.
In addition, if someone adds a property to `Object.prototype` might
also create unexpected results.

This pull request fixes it, with it an appropriate error is thrown.

PR-URL: #5843
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

evanlucas pushed a commit that referenced this pull request

Mar 31, 2016 
Currently we use `{}` for the `lookup` function to find the relevant
resolver to the dns.resolve function. It is preferable to use an
object without a Object.prototype, currently for example you can do
something like:

```js
dns.resolve("google.com", "toString", console.log);
```

And get `[Object undefined]` logged and the callback would never be
called. This is unexpected and strange behavior in my opinion.
In addition, if someone adds a property to `Object.prototype` might
also create unexpected results.

This pull request fixes it, with it an appropriate error is thrown.

PR-URL: #5843
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

MylesBorins pushed a commit that referenced this pull request

Apr 8, 2016 
Currently we use `{}` for the `lookup` function to find the relevant
resolver to the dns.resolve function. It is preferable to use an
object without a Object.prototype, currently for example you can do
something like:

```js
dns.resolve("google.com", "toString", console.log);
```

And get `[Object undefined]` logged and the callback would never be
called. This is unexpected and strange behavior in my opinion.
In addition, if someone adds a property to `Object.prototype` might
also create unexpected results.

This pull request fixes it, with it an appropriate error is thrown.

PR-URL: #5843
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>