Use unix domain socket as proxy addr?

[donmor]

Describe the solution you'd like

I'm not sure if setting PROXY_HTTP_ADDR=unix:///var/run/ocis.sock will work. It'd be good if ocis have this feature (secured local connections between ocis and reverse proxies)

Describe alternatives you've considered

Another variable PROXY_SOCKET that accept a path to a socket.

[jvillafanez]

As far as I know, this is untested and unlikely to work. You can give it a try if you want, but don't expect much.

From an architectural POV, I don't think it's a good idea.
In general, each app component (ocis, reverse proxy, office app...) should be deployed in different hosts. For convenience, we try to wrap everything in a docker-compose file to deploy everything needed in the same host but different containers, faking that environment. In fact, each ocis service can be deployed in different hosts.
Basically, the goal is that each ocis microservice can be deployed and replicated in different hosts. Being able to deploy everything in the same host is just a convenient scenario.

All the ocis microservices use the localhost network by default, and the reverse proxy can access to ocis via localhost while exposing just the required entrypoint. This should be good enough if you're the only user in the host.

Using docker and the recommended docker-compose files, the deployment will be behind a docker network in an isolated environment. This should add an additional layer of security.

I'm not sure if adding support for unix sockets is worthy in this case. I mean, using docker (recommended) should be fine; if you don't want to use docker, deploying ocis in localhost should also be fine (assuming you're the only user in the host). The only reason I see to use unix sockets would be performance, but I don't know how it compares with using localhost.
Now, assuming there is a noticeable performance increase with unix sockets, is it worthy to implement it for a convenient scenario but not for the general one? Note that we're "promoting" the docker deployments because they're easy to setup, and those won't benefit from the change.