Settings

Theme

Dillo RFC 003 – Unix sockets in URLs

dillo-browser.github.io

3 points by rodarima a year ago · 9 comments

Reader

rodarimaOP a year ago

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/

  • hello_computer a year ago

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

       unix:///tmp/my.sock
    • rodarimaOP a year ago

      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/
      • hello_computer a year ago

        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.

        • rodarimaOP a year ago

          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.
          • hello_computer a year ago

            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.

            • rodarimaOP a year ago

              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?

              • niutech a year ago

                *.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://

    • niutech a year ago

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

Keyboard Shortcuts

j
Next item
k
Previous item
o / Enter
Open selected item
?
Show this help
Esc
Close modal / clear selection