Is there a way to use a unix socket?

[bbigras]

I would like to do the equivalent of:

curl --unix-socket /var/run/docker.sock http://localhost/containers/json

There's the unix_socket crate but I'm not sure if I can use it with reqwest.

[seanmonstar]

There isn't a way yet, but it definitely makes sense to provide when cfg(unix)!

What makes sense for the best way to provide this? Just adding to the connector to look for the unix:// scheme? There doesn't seem to be a standard way to handle this, as I look up various HTTP libraries.

[stephanbuys]

The unix:// scheme seems to be well established, I'd recommend doing what you propose.

[bbigras]

The url crate seems to support the unix:// scheme (see example).

let url = Url::parse("unix:/run/foo.socket").unwrap();

Would it be possible to include the path with something like this?

let url = Url::parse("unix:/var/run/docker.sock/containers/json").unwrap();

I'm also wondering if localhost is passed to the unix socket. If so, I don't know how it would be possible to specify it (or another vhost) using the unix:// scheme.

According to the Docker Remote API page, older curl version used http://containers/json as the URL so I don't know if the localhost part is used.

[seanmonstar]

So looking around, I see two possible routes.

• As curl does it, which is to not use the URL to indicate that a unix socket should be used instead of TCP. This could either be a single constructor on the client, like Client::unix_socket("/var/docker.sock"), or it could be considered a "proxy", and thus as suggested in API for setting an HTTP proxy for a Client #30, be something like Proxy::unix("/var/docket.sock").
• Using the URL, something like requests-unixsocket, with an example of http+unix://%2Ftmp%2Fprofilesvc.sock/path/to/page. This is a whole lot uglier, but allows all the semantics to exist in the Url, such as whether to use TLS, and is possibly easier to allow dynamic selection of which unix socket.

[lucab]

@seanmonstar in case you were looking for feedback, I definitely prefer the first option because it allows to leave the scheme and host-fqdn part untouched. This is important if at the other end of the unix-socket there is a virtualhost-aware server, or something doing TLS-ALPN (or similar upper protocol detection/negotiation).

[mathstuf]

I've wanted "use a socket for HTTP requests" for a while because setting up a proxy on a port doesn't lock it down to just the current user. Not that that project is ever going to use Rust at its network level anytime soon, but it's not an unheard of use case.

[seanmonstar]

I think I prefer this being Proxy::unix(path). For implementation details, it'd need to be slightly different since it would actually connect a unix stream instead of just give a new URL.

[farodin91]

Any progress in this area?

[mathstuf]

Doing some research in how it is done elsewhere:

• Apache HTTP it looks like fcgi://socket=%2ftmp%2fphp-fpm.sock/local/htdocs/ is proposed. Though it seems that actual support may be unix:///var/run/php-fpm.sock|fcgi://127.0.0.1:9000/srv/www/$1
• NodeJS uses named options.
• Here is my libsoup thread about it. (The thread continues into February as well.)

[farodin91]

I saw a implementation of unix socket in boondock using hyper 0.9.0 https://github.com/faradayio/boondock/blob/master/src/unix.rs

[mathstuf]

This also might not be a non-Windows thing in the future as well: https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/

[jjl]

I came across the hyperlocal crate today which might be of interest

[Roguelazer]

Is there any workaround now? I was looking at something with the xmlrpc crate (which uses reqwest by default) but unix sockets are a must-have for my environment and it looked like all the Transport stuff in reqwest is currently hidden away in the async_impl module; there didn't seem to be any hooks in ClientBuilder where I could shove a custom Transport.