Repository navigation
net.Server.address() returns a string instead of an object for Pipes #12895
Description
Activity
- changed the title
[-]net.Server.address() returns a string instead of an object[/-][+]net.Server.address() returns a string instead of an object for Pipes[/+]on May 8, 2017 const http = require("http"); const util = require("util"); const tcpServer = http.createServer().listen(8000); const pipeServer = http.createServer().listen("\\\\.\\pipe\\thePipeName"); console.log(`tcpServer: ${util.inspect(tcpServer.address())}`); console.log(`pipeServer: ${util.inspect(pipeServer.address())}`);It's also applicable to Linux but there it's not a named pipe it's an unix domain socket which is handled by the same class in node.
see net.js:
Server.prototype.address = function() { if (this._handle && this._handle.getsockname) { var out = {}; this._handle.getsockname(out); // TODO(bnoordhuis) Check err and throw? return out; } else if (this._pipeName) { return this._pipeName; } else { return null; } };Reacted by Refael AckermannAs far as I know there is no API to check if a Server is using a Pipe or TCP besides checking the type of the internal
_handlemember which is not that nice.
Not sure if such an API is worth to add.
Not sure if it is really possible as anything with an_handleorfdmember can be passed to listen therefore it's not really possible to tell what the server is actually listening on.I’d prefer just documenting this rather than risking breakage. As @Flarna pointed out, there wouldn’t really be any point in switching to an object.
🤔 is would be nice to have a way to get the
typeof underlying medium, so we could know what to expect fromserver.address()(AFAIK is could be an; fd / UNIX socket / TCP socket / Windows Pipe)As long as we have only TCP and Pipes it's fine. Not sure if all usecases of
listen()nail down to this two cases.- added a commit that references this issue
on May 19, 2017 - added a commit that references this issue
on Jun 20, 2017 - added a commit that references this issue
on Jul 11, 2017 - added a commit that references this issue
on Jul 23, 2019 - added a commit that references this issue
on Jul 27, 2026
According to the documentation
server.address()should return an object withport,family, andaddressproperties but if I call it on a HTTP server connected via windows pipe (on IIS Node on Windows Azure) I get a plain string telling the pipe name.Is this just a documentation issue or should the return value for the pipe case adapted somehow (even port/familiy doesn't make that much sense for a pipe).