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

You're right, this is the url repo on GitHub, and as such would be the place to define a URL standard for encoding a Unix domain socket path.

The Unix socket paths would of course be interpreted in an OS-dependent manner, which is generally not a problem at all. Consider `file:///` URLs in Windows, which are typically of the form `file:///C:/Users/Username/Example`. Even though Windows uses drive letters rather than a root hierarchy like on Unix-like systems, it is still able to make use of `file:///` URLs, by encoding the pathname in a clear and straightforward manner, representing `C:\Users\Username\Example` as `/C:/Users/Username/Example`.

All of the comments above would effectively be means of encoding a file path string in place of the domain name or IP address of a URL string. This is not much different from the specification of an "interface" in a programming language like Java or Go, which generally specify what is available to a user and what functions an implementation has to implement, but they generally do not specify how they should be implemented. And as discussed above, Windows `file:///` URLs are different from Unix `file:///` URLs. That is, while both Windows and Unix use the common interface of a `file:///` URL, they implement them differently. And that's not a problem at all.

Which means that we can effectively generalize this issue from "encoding a Unix socket path" to "encoding a filesystem path like string which acts as the equivalent of a hostname, which could be interpreted in a system-dependent manner". And just like how I mentioned that `file:///` URLs can be chrooted, all of the following could theoretically be possible for the "Unix domain socket URL scheme":

* Limit the set of available sockets to a certain directory.
* Map certain prefixes of the filesystem path string to a multitude of directories.
* Interpret certain prefixes of the filesystem path string as other types of sockets.
* Apply different restrictions to different prefixes of the filesystem path string.
* Create an LD_PRELOAD library which intercepts AF_UNIX calls to connect to sockets of other types.

So I'm quite supportive of the issue at hand, so long as it's not restricted to AF_UNIX sockets, because if we need to support other types of transport, then we won't need to have all of this discussion again.

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

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