-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net.Server.address() returns a string instead of an object for Pipes #12895
Comments
Hello @Flarna could you provide a code snippet? |
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. |
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:
|
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 |
@Flarna Doesn’t checking the return type of |
🤔 is would be nice to have a way to get the |
As long as we have only TCP and Pipes it's fine. Not sure if all usecases of |
@Flarna Yes, those two are the only supported options (for |
Add documentation for net.server.address() for the case it is listening on a pipe or unix domain socket instead an IP socket. PR-URL: nodejs#12907 Fixes: nodejs#12895 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
Add documentation for net.server.address() for the case it is listening on a pipe or unix domain socket instead an IP socket. PR-URL: #12907 Fixes: #12895 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
Add documentation for net.server.address() for the case it is listening on a pipe or unix domain socket instead an IP socket. PR-URL: #12907 Fixes: #12895 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
…rred. This is necessary after the changes in 0f75909 and #2344, as the `AddressInfo` type didn't become available until a future version of `@types/node`. Regardless, it seems to me that this should be inferred without any problem and we don't actually rely on the `AddressInfo` type, and instead are only looking for an interface which has `port`, `address` and `family`, as the inferred return value from `http.Server.prototype.address()` does.
According to the documentation
server.address()
should return an object withport
,family
, andaddress
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).
The text was updated successfully, but these errors were encountered: