Dillo RFC 003 – Unix sockets in URLs | Hacker News Reader

Dillo RFC 003 – Unix sockets in URLs

dillo-browser.github.io

3 pointsrodarima9 comments

I just wrote a simple RFC to support UNIX sockets in URLs, initially for Dillo[1] but potentially useful for other software.

It allows protocols other than HTTP to talk to the socket, like Gemini or Gopher.

[1]: https://dillo-browser.github.io/

why waste a tld when URLs already have a protocol component?

   unix:///tmp/my.sock

To easily run a HTTP service that only your user can talk to.

    echo 'unix:/tmp/my.sock weather.unix' >> ~/.config/unix.hosts
    dillo http://weather.unix/today/

i understand that. i mean why not just follow the existing url spec and implement handling stream sockets in the browser (i.e. type ‘unix:///tmp/my.sock’ into the url bar and go). we can already open files that way. if the chrome guys are going to be obstructionist about it, there must be several pipe-to-http connectors out there. it’s a few lines in c or go.

Because there are multiple protocols you could be using to talk to the socket other than HTTP. In order to use HTTP, you also need to specify the path and maybe other elements. What you may want is something like:

    http://<unix:///tmp/my.sock>/foo/bar.html?good=yes

To avoid the nesting of protocols, I think it is cleaner to give it a name and define the socket path elsewhere.

sorry, forgot about ftp:// and ws://. i think your comment is a better approach than the original RFC. the hosts file approach is overwrought, and trouble waiting to happen.

There are some benefits in using an alias instead.

First, it is easier and shorter to type and remember, as the path to the socket can be long. Second, multiple users may run a given service in a socket located at different paths. And third, using a host name can be used to create virtual hosts, so you can serve different responses to foo.unix and bar.unix while both point to the same server UNIX socket.

If you see a problem with using a host file, could to provide an example of how it could go wrong?

*.unix TLD could be sold in the future. Why not use *.local if you insist on a domain name? However I'd prefer a different protocol, like http+unix://

Or reuse the existing protocol: file:///tmp/my.sock

Reply on news.ycombinator.com