Wiki¶

Issues¶

If package.json's 'main' does not resolve, no error reported and resolution continues #9118 (Danny)¶

Summary¶

something should warn that "typo.js" does not resolve to anything
module resolution should halt and report an error
Actual behavior:

require() fails quietly, and continues to search all the module paths for a module
This is particularly bad due to the OS-dependent case-sensitivity problems with require(), because you can have a module that resolves to one version on one platform, and to another >version on another platform.

Replication¶

Create a node_modules/a/package.json that looks like this: {
"name": "a",
"main": "typo.js"
}
where typo.js does not resolve to a file. Then execute require('a')

Notes¶

None Yet.

Inconsistency in stringification of parsed query with valueless key #8825 (Harrison) -- Fixed¶

Summary¶

text

Replication¶

var query = querystring.parse('api&uid=1234&pwd=abc1234');
// { api: '', uid: '1234', pwd: 'abc123' }
querystring.stringify(query);
// api=&uid=1234&pwd=abc1234

Notes¶

These files contain info about how string queries are handled, and may prove useful:
/doc/api/querystring.markdown
/doc/api/utils.markdown
The issue is likely in /lib/querystring.js in the stringifty and parse methods.

There are two methods involved, parse and stringify. The replication code breaks in parse, which should pass through null to stringify. Stringify seems to not show the '=' if the input value is null.

Lines 150 through 162 were added to fix bug. Line 150: If statements were added to check if v === 'null', if true, don't print = sign.
Line 160 if v === 'null' push an empty string to the stringify stack
Current temporary fix on line 220 in /lib/querystring.js/.
Adds null by default unless there is a value.

net: unref() is not persistent #7077 -- Fixed¶

Summary¶

When unref() is called on a socket, It hangs and then fails with ECONNREFUSED because the unref() is a no-op. The expected behavior for both scripts is that they simply quit.

Replication¶

Save this file test.js for the unref() bug and run it by giving the command node test.js. It should reproduce the error on an unfixed version

Notes¶

The bug is produced because there isn't a way for node to keep track of the server being referenced or unreferenced. This can be achieved by simply adding one more flag to it.
The flag to add is the unref flag, and and change it to true/false depending on its previous state.

dns.setServers() crash #9243 (Donnie)¶

Summary¶

In a vagrant Ubuntu Environment VMware, the assertion made is set to catch the in flight data while servers are being switched. When the code is executable, it has too much latency to be considered a successful attempt. At this point, the fix for the code throws a critical error that crashes the code right from the start.

Notes¶

This is the code that crashes.

$ cat dns.js
var dns = require('dns');

console.log(soa.nsname);
dns.resolve4(soa.nsname, function (err, nameServers) {
console.log(dns.getServers());
dns.setServers(nameServers);
console.log(dns.getServers());
});
});

The actual result has issues with the dns.getservers.
Possible fixes take too long to run.
The issue will most likely be resolved if the requests and calls are separated and executed to avoid the code getting in it's own way.

socket options ignored before you connect #8572 -- Fixed¶

Summary¶

The setKeepAlive and setNoDelay are ignored.

Notes¶

This involved addenda variables in net.js to keep track if those options were actually used and then apply them

Feature Requests¶

Add interval and count options to setKeepAlive() #4882 (Donnie)¶

Summary¶

The setKeepAlive() bug was fixed by someone else after team Slaking chose it as a target. This issue was fixed by adding a probeinterval and failure count to regulate time between setKeepalive calls and monitor number a failed calls before termination. Since this issue was fixed another bug was added to the list.

Notes¶

None Yet.

Missing a way to get local IP address for received UDP message #8788 (Mike)¶

Summary¶

Suppose a server has addresses 1.2.3.4 (primary) and 5.6.7.8 (secondary). Then suppose that someone from the address 9.10.11.12 sends a UDP packet:

9.10.11.12:678 -> 5.6.7.8:345

In C, on the server, I could use IP_PKTINFO (Linux) or IP_RECVDSTADDR (FreeBSD) to get the "5.6.7.8" and produce a reply going from the correct address (5.6.7.8, not 1.2.3.4). In node.js,
there is no way to get that.

Notes¶

Optimal Locations for this code appear to be in:
/lib/_http_agent.js
/lib/_http_server.js
/lib/_http_incoming.js
/lib/http.js
/lib/https.js
/lib/net.js

I am expecting various dependencies to be important, as there are many libraries that handle http connections and the server code. I also think that this will be dependent on the operating
system of the server, as IP_RECVDSTADDR will not work on dualstack connections on most Unix/BSD operating systems. Not sure about Windows.

These files contain information about how http connections are handled, and could be useful:
/doc/api/http.markdown
/doc/api/https.markdown
/doc/api/net.markdown
/doc/api/url.markdown

net: Allow custom DNS resolvers #8475¶

Summary¶

The feature request is to allow the user to add a custom dans resolver instead of using the system default

Notes¶

None Yet.

Files:¶