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.

Require('buffer').INSPECT_MAX_BYTES usage is off-by-one #7995 (Danny)¶

Summary¶

Pretty self explanatory.

Replication¶

require('buffer').INSPECT_MAX_BYTES = 2;
console.log(new Buffer([0,1,2,3]));

Expected:
<Buffer 01 02 ...>

Actual:
<Buffer 01 02 03 ...>

Looks like there used to be some tests for this: https://github.com/joyent/node/blob/a18c9b7dde22cce6cec5d47cfd6a16694c9992e8/test/simple/test-buffer-inspect.js

Notes¶

None Yet.

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

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

net: unref() is not persistent #7077¶

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 give an error

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.

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.

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

Files:¶