1. 12
  1.  

    1. 3

      Of course, your OS might not support Unix sockets – I don’t know if there’s an equivalent on Windows.

      Looks like Windows has support for UNIX domain sockets: https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/

      1. 1

        A named pipe server would work roughly the same way for this too. Or just listening to localhost only on tcp is probably good enough really…

        1. 1

          The benefit of UNIX domain sockets is that you can use the filesystem permissions to do access control.

          1. 1

            That’s also basically true of a Windows named pipe server, you can set ACLs on it similarly to files. I’m not sure if you can get the peer username in a named pipe like you can in a unix domain socket but i think you can.

            But yeah, of course, you can’t do any of this with a localhost tcp server, but tbh the different user accounts on a server are often academic anyway; everybody sudos all the time hence me figuring that’s probably good enough. And has the benefit of working with more generic tools that speak http/tcp but might not speak http/uds or http/named pipe.

            1. 1

              This hardly depend on the type of server and on your general setup. For servers on multi-user clients (i.e. a display manager) you might not want to bind your admin interface to localhost. On shared hosting servers binding the admin interface to localhost is not the best idea.

    2. 2

      This is how Caddy works. It’s all configured through a sidecar webserver.

    3. [Comment removed by author]