3 ms·
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
by hello_computer 2y 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.
- rodarima 2y agoBecause 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 2y agosorry, 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.
- rodarima 2y agoThere 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 2y 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://