7.9.0Darwin MacBook-Air-de-paul-7.local 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64Hi guys,
On my version/platform it is possible to launch a server with an undefined port. This is misleading given that there's no error message and you believe the server is working but in fact it does not listen at all. On other versions it throws a RangeError.
A complete history can be found here: https://github.com/expressjs/express/issues/3364 but Doug (https://github.com/dougwilson) gave me this one liner which makes it easy to test:
Thanks,
Paul
node -pe 'require("http").createServer(function(){}).listen(undefined, function(){})'
Server {
domain: null,
_events:
{ request: [Function],
connection: [Function: connectionListener],
listening: { [Function: bound onceWrapper] listener: [Function] } },
_eventsCount: 3,
_maxListeners: undefined,
_connections: 0,
_handle:
TCP {
bytesRead: 0,
_externalStream: {},
fd: 11,
reading: false,
owner: [Circular],
onread: null,
onconnection: [Function: onconnection],
writeQueueSize: 0 },
_usingSlaves: false,
_slaves: [],
_unref: false,
allowHalfOpen: true,
pauseOnConnect: false,
httpAllowHalfOpen: false,
timeout: 120000,
_pendingResponseData: 0,
maxHeadersCount: null,
_connectionKey: '6::::0' }
if you change that one liner to node -pe 'var s = require("http").createServer(function(){}).listen(undefined, function(){}); s.address()' you'll see that undefined will be converted to 0, which will allow the OS to assign a random port.
Hi Evan,
my initial code was:
// start the server
console.log('process.env.PORT', process.env.PORT)
app.listen(process.env.PORT, function () {
console.log(`Server is running on port ${port}`)
})
In that context process.env.PORT was undefined and node was not complaining.
yes, it doesn't complain because when a port is undefined, we treat it like it's 0 and the OS will choose the port. So it listens, it just listens on a random port. To get the port, you can access server.address().port
This behavior has recently changed, maybe a few lines in that section of the docs would be good, because I just tried it with node 8.x and 6.x. In node 6 null and 0 work, undefined fails. In node 8, null fails and 0 and undefined work.
EDIT: we have been using null for this since like node 0.8 or something, so this recent update broke us, hence why I noticed this conversation starting over on the express repo :)
This is a regression, IMO.
6.x and 8.x doing the opposite of each other doesn't look intentional, both should behave like 4.x.
% nvm i 4
Downloading https://nodejs.org/dist/v4.8.4/node-v4.8.4-linux-x64.tar.xz...
######################################################################## 100.0%
Now using node v4.8.4 (npm v2.15.11)
% node -pe 'var s = require("http").createServer(function(){}).listen(undefined, function(){}).unref(); s.address()'
{ address: '::', family: 'IPv6', port: 36947 }
% node -pe 'var s = require("http").createServer(function(){}).listen(null, function(){}).unref(); s.address()'
{ address: '::', family: 'IPv6', port: 46595 }
% nvm i 6
Downloading https://nodejs.org/dist/v6.11.1/node-v6.11.1-linux-x64.tar.xz...
######################################################################## 100.0%
Now using node v6.11.1 (npm v3.10.10)
% node -pe 'var s = require("http").createServer(function(){}).listen(undefined, function(){}).unref(); s.address()'
internal/net.js:17
throw new RangeError('"port" argument must be >= 0 and < 65536');
^
RangeError: "port" argument must be >= 0 and < 65536
at assertPort (internal/net.js:17:11)
at Server.listen (net.js:1389:5)
at [eval]:1:52
at ContextifyScript.Script.runInThisContext (vm.js:25:33)
at Object.runInThisContext (vm.js:97:38)
at Object.<anonymous> ([eval]-wrapper:6:22)
at Module._compile (module.js:570:32)
at evalScript (bootstrap_node.js:353:27)
at run (bootstrap_node.js:122:11)
at run (bootstrap_node.js:389:7)
% node -pe 'var s = require("http").createServer(function(){}).listen(null, function(){}).unref(); s.address()'
{ address: '::', family: 'IPv6', port: 40967 }
% nvm i 7
Downloading https://nodejs.org/dist/v7.10.1/node-v7.10.1-linux-x64.tar.xz...
######################################################################## 100.0%
Now using node v7.10.1 (npm v4.2.0)
% node -pe 'var s = require("http").createServer(function(){}).listen(undefined, function(){}).unref(); s.address()'
{ address: '::', family: 'IPv6', port: 41121 }
% node -pe 'var s = require("http").createServer(function(){}).listen(null, function(){}).unref(); s.address()'
net.js:1422
throw new Error('Invalid listen argument: ' + options);
^
Error: Invalid listen argument: [object Object]
at Server.listen (net.js:1422:9)
at [eval]:1:52
at ContextifyScript.Script.runInThisContext (vm.js:23:33)
at Object.runInThisContext (vm.js:95:38)
at Object.<anonymous> ([eval]-wrapper:6:22)
at Module._compile (module.js:571:32)
at evalScript (bootstrap_node.js:391:27)
at run (bootstrap_node.js:124:11)
at run (bootstrap_node.js:427:7)
at startup (bootstrap_node.js:123:9)
% nvm i 8
Downloading https://nodejs.org/dist/v8.1.4/node-v8.1.4-linux-x64.tar.xz...
######################################################################## 100.0%
Now using node v8.1.4 (npm v5.0.3)
% node -pe 'var s = require("http").createServer(function(){}).listen(undefined, function(){}).unref(); s.address()'
{ address: '::', family: 'IPv6', port: 33561 }
% node -pe 'var s = require("http").createServer(function(){}).listen(null, function(){}).unref(); s.address()'
net.js:1479
throw new Error('Invalid listen argument: ' + util.inspect(options));
^
Error: Invalid listen argument: { port: null }
at Server.listen (net.js:1479:9)
at [eval]:1:52
at ContextifyScript.Script.runInThisContext (vm.js:44:33)
at Object.runInThisContext (vm.js:116:38)
at Object.<anonymous> ([eval]-wrapper:6:22)
at Module._compile (module.js:569:30)
at evalScript (bootstrap_node.js:432:27)
at startup (bootstrap_node.js:139:9)
at bootstrap_node.js:575:3
@sam-github I agree. I didn't realize this behavior had changed
@cjihrig I'm working on fix for 6.x, FYI /cc @nodejs/lts
Most helpful comment
This is a regression, IMO.
6.x and 8.x doing the opposite of each other doesn't look intentional, both should behave like 4.x.