Hacker News Reader

Comment by hello_computer | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com