net.Server.address() returns a string instead of an object for Pipes

Version: 6.10.0
Platform: Windows
Subsystem: net

According to the documentation server.address() should return an object with port, family, and address properties 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).

@Flarna

Hello @Flarna could you provide a code snippet?

@Flarna

net.createServer().listen('foo', function() { console.log(this.address()); })

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.

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;
  }
};

As 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 _handle member 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 _handle or fd member can be passed to listen therefore it's not really possible to tell what the server is actually listening on.

@Flarna

@Flarna Doesn’t checking the return type of .address() basically do that? ;)

@Flarna

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 type of underlying medium, so we could know what to expect from server.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.

@Flarna

@Flarna Yes, those two are the only supported options (for net.Servers, at least). :)

doc: add docs for server.address() for pipe case

Stop casting to `net.AddressInfo` type as that should already be infe…

doc: add docs for server.address() for pipe case

Navigation Menu

Repository navigation

net.Server.address() returns a string instead of an object for Pipes #12895

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

net.Server.address() returns a string instead of an object for Pipes #12895

Description

Activity

refack commented on May 8, 2017

addaleax commented on May 8, 2017

Flarna commented on May 8, 2017

Flarna commented on May 8, 2017

addaleax commented on May 8, 2017

refack commented on May 8, 2017

Flarna commented on May 8, 2017

addaleax commented on May 8, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions