Re: [whatwg/url] Addressing HTTP servers over Unix domain sockets (#577)

> > Unix domain sockets are an OS-specific transport. Windows has named pipes instead.
> 
> AFAIU, [AF_UNIX has come to Windows](https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/).
> 

True, I know that AF_UNIX does exist on Windows. But the idea of mapping IPv6 addressing to Unix sockets would not be limited to Unix sockets, but rather also to other stream-based TCP-like transports like `AF_VSOCK`.

> > For example, one could connect to fe8f::3:6:0 port 12345, and it would map to a Unix socket at /run/00006/00000_12345.
> 
> One benefit of filesystem sockets is that you can skip the numeric address part and directly map human-friendly names (virtual hostnames) into (human-friendly) paths. This way you avoid the cumbersome task of managing a mapping human-firendly virtual hostnames into numeric addresses.

The same effect could be accomplished by putting one of those IP addresses into the `/etc/hosts` file, resulting in a mapping from a human-friendly domain to the IP address which maps to the unix socket. This also means that there would not need to be any changes to SSL/TLS certificates either, one can continue to use DNS subject alt names.

The connection to `fe8f::3:6:0` port 12345 is not an actual TCP connection, but is specially interpreted by a modification of the `connect()` system call in the TCP/IP socket API, causing a connection to a Unix domain socket rather than a TCP socket. This is implemented by my socketbox and u-relay-tproxy projects (see my github profile).

The advantage of this mapping is that the set of allowed Unix domain sockets that could be connected to is naturally restricted to the end-user-defined mapping of IPv6 prefixes to filesystem path prefixes. Only the unix sockets under path prefixes mentioned in a user-defined mapping would be visible to the application. (To put things another way, the `file://` URL scheme could also be sandboxed to a chroot, and the view of the filesystem as observed through `file://` URLs can still be totally valid.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/577#issuecomment-2382201237
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/577/2382201237@github.com>