Conversation

Notices

1. Embed this notice
   Dillo browser (dillo@fosstodon.org)'s status on Tuesday, 31-Dec-2024 02:35:20 JST Dillo browser

   Here is a new #Dillo #RFC to support UNIX sockets in URLs. Comments?

   https://dillo-browser.github.io/rfc/003-unix-sockets/

   • Embed this notice
     Dillo browser (dillo@fosstodon.org)'s status on Tuesday, 31-Dec-2024 04:08:34 JST Dillo browser

     in reply to

     • Tim Chase

     @gumnos yes, it would require the IANA to reserve .unix for UNIX sockets to avoid collisions.

     The RFC specifies how a user can override a system-wide UNIX host by setting it in their own unix.hosts file (maybe at ~/.config/unix.hosts), which takes priority over /etc/unix.hosts.

     Using "socket:" doesn't specify the protocol to use *inside* the socket. A single unix socket could serve multiple "hosts" via HTTP by using the Host: header. What problem does using the full path solve?

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Tim Chase (gumnos@mastodon.bsd.cafe)'s status on Tuesday, 31-Dec-2024 04:08:36 JST Tim Chase

     in reply to

     @dillo without a proper RFC/registration of a .unix TLD, this can cause possible problems. The footnote at that URL mentions that it doesn't exist, but that doesn't prevent it from appearing in the future. So if it were to move forward, I would want to see it officially RFC-spec'ed similar to .invalid or .local or .internal

     The /etc/hosts (or unix.hosts) hack feels a bit…unfortunate. It prevents non-admin users (who can't edit /etc/hosts) from adding endpoints.

     I'd much rather see it done via the protocol, maybe something like

     socket:///path/to/socket:/path/to/resource