Windows: AF_UNIX unix:// URLs fail to parse and round-trip

[stantheman0128]

Summary

On Windows, in-tree AF_UNIX discovery tests fail at HEAD (3c4dec3). Named-pipe (npipe://) tests on the same machine pass. No container runtime is involved.

I intend to implement a fix. Per CONTRIBUTING I will wait for assignment before opening a PR.

Environment

• Windows 11, go version go1.26.5 windows/amd64
• HEAD: 3c4dec3

go test ./pkg/server/discovery/ -count=1 -run "TestParseUnixSocketPath_Valid$|TestHTTPClientForURL_SchemeDispatchCaseInsensitive|TestCheckHealth_UnixSocket_Success$"

Failures

POSIX unix:/// paths rejected as relative

ParseUnixSocketPath("unix:///var/run/thv.sock") returns:

unix socket path must be absolute: \var\run\thv.sock

filepath.Clean on Windows turns /var/run/thv.sock into \var\run\thv.sock, and filepath.IsAbs is false because there is no volume. Same for HTTPClientForURL("UNIX:///tmp/thv.sock") -> \tmp\thv.sock.

Concatenating unix:// + a drive path is not a valid URL

TestCheckHealth_UnixSocket_Success builds "unix://"+socketPath. On Windows that is unix://C:\Users\...\test.sock. url.Parse rejects it:

invalid server URL: parse "unix://C:\\Users\\stans\\AppData\\Local\\Temp\\thv-3078206842\\test.sock": invalid port ":\\Users\\stans\\AppData\\Local\\Temp\\thv-3078206842\\test.sock" after host

pkg/api/socket_windows.go already documents this and emits unix:///C:%5Cpath%5Cthv.sock. The discovery tests still concatenate.

ListenURL four slashes

Windows socketURL does Path: "/" + address. When address is already /tmp/test.sock, ListenURL returns unix:////tmp/test.sock (four slashes) instead of unix:///tmp/test.sock. The Unix build of socketURL uses Path: address and does not add that extra slash.

What is not broken

• Named-pipe setup, DACL, and first-instance-wins tests are green.
• TestSocketURL_RoundTrip_AFUnix for C:\path\thv.sock via socketURL() already percent-encodes correctly.

Direction (after assignment)

Keep the three-slash encoded form that socket_windows.go already documents. Make ParseUnixSocketPath accept POSIX unix:///var/run/... on Windows (or skip those cases on Windows). Stop tests from concatenating unix:// + a drive path; use socketURL / url.URL. Do not prepend / when address already starts with /.

Happy to take this once assigned.

Filed with AI assistance (Cursor/Grok). Reproduced on this machine.

[stantheman0128]

I'd like to work on this.

[stantheman0128]

Follow-up: TestListenURL/Unix_socket_returns_unix_URL on the same box:

expected: "unix:///tmp/test.sock"
actual  : "unix:////tmp/test.sock"

go test ./pkg/api/ -count=1 -run TestListenURL (go1.26.5 windows/amd64, HEAD 3c4dec3).

[reyortiz3]

Thanks for the detailed report, @stantheman0128, and for the exact repro commands and root-cause analysis on all three cases. We have read this and it is noted, but it is not something we are prioritizing right now, so we are leaving it open.

You mentioned waiting for assignment, so we have gone ahead and assigned this to you. Your direction sounds right to us: accepting POSIX unix:/// paths on Windows, fixing the test concatenation, and dropping the extra slash in ListenURL. Feel free to open a PR whenever you are ready, and tag us if you want feedback on direction before you go deep.

Thanks again for taking the time to file this.

[stantheman0128]

Thanks @reyortiz3. I will open a PR for the three items you listed: accept POSIX unix:/// paths on Windows, fix the test concatenation, and drop the extra slash in ListenURL.

[stantheman0128]

Thanks @reyortiz3. I'll open a PR on the three cases you confirmed.

Re-checked current main on Win11: drive-letter emit/parse already uses the three-slash form. What still fails here is POSIX unix:/// (ListenURL becomes unix:////tmp/..., and ParseUnixSocketPath rejects \var\run\thv.sock as relative) plus health tests that concatenate unix:// onto a Windows path. I'll fix that at the URL helper rather than with three one-off patches.