http.request socketPath doesn't work on Windows

[sschultze]

When calling http.request with the socketPath option on Windows in order to try to connect to a Unix domain socket, I get the following error message:

Error: connect ENOTSOCK C:\Users\User\AppData\Local\Temp\test.sock
    at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1141:16)

There is native Unix Domain Sockets support in Windows 10 since two years, and the documentation at https://nodejs.org/api/http.html gives no indication that socketPath doesn't work on Windows, so I guess that this can be considered as an error.

• Version: 12.16.3 (comes with Electron 10.1.0)
• Platform: Windows 10, 64-bit, Build 18362.19h1_release.190318-1202
• Subsystem: http

What steps will reproduce the bug?

Call http.request with the socketPath option on Windows. Specify a Unix domain socket path.

[lpinca]

You have to use a named pipe on Windows, see https://nodejs.org/api/net.html#net_ipc_support. AFAIK Node.js does not support UDS on Windows.

[lpinca]

cc: @nodejs/platform-windows @nodejs/net @nodejs/libuv

[arixmkii]

AF_UNIX sockets on Windows were marked GA in build 18362 of Windows 10.

According to this list from MS, the only version, still within the window Mainstream support w/o support is Enterprise/IoT LTSC 1809.

It looks like this could be considered supported for all mainstream Windows versions. Would be nice to have this feature supported as many other languages has this implemented in their runtimes.

[bnoordhuis]

Blocked on libuv/libuv#2537.

[ravicious]

At Teleport we develop a multi-platform Electron app which talks to a local daemon over gRPC. Since Node.js on Windows doesn't support Unix sockets, we use gRPC over TCP with mTLS to keep it secure. See CVE-2022-41924 for a vulnerability which depended on Tailscale running an unsecured HTTP API over TCP vs running the same API over a socket on unixes.

Unix socket support on Windows would mean that we can completely remove the mTLS setup and all ceremonies related to it with a much simpler socket based solution. TCP + mTLS was preferred over named pipes due to another team reportedly having bad time with them on Windows.

[bnoordhuis]

This is basically "pull request welcome" territory although it's intricate and laborious enough that it likely needs (edit: libuv and node) maintainer involvement. Probably a day or two, three of work. Get in touch if you want to sponsor it.