🧱 add support for unix sockets

[jbr]

This is a draft because it depends on http-rs/http-service#64 which in turn depends on http-rs/async-h1#107

[xpepermint]

I created the async-uninet crate which might be useful.

[yoshuawuyts]

I'm wondering whether instead of exposing only UDS support, we could add support for any IO source. This would allow us to run HTTP/1.1 over any IPC channel. Thanks to http-rs/async-h1#107 this is now a lot easier. I see two ways of doing that:

• Server::listen_on(self, io: impl AsyncRead + AsyncWrite) -- add a new method that allows listening on specific streams.
• Server::listen(self, opts: Into<ServerOptions>) -- have some way to construct server options that can be passed to Server::listen. One such option could be the stream.

[jbr]

The bounds for the rw/io are currently slightly more than just Read+Write, but that's basically how the http-service layer is set up. I figured the tide layer would want to be a bit more specific, especially since currently the Clone bound requires a wrapper for some streams. Probably most of the interesting stuff is in http-rs/http-service#64. I couldn't figure out how to make the wrapper generic (literally exactly https://blog.yoshuawuyts.com/io-trait-delegation-for-arc/, but wasn't sure if https://docs.rs/io-arc/1.0.0/io_arc/ was ready to use)

[yoshuawuyts]

currently the Clone bound requires a wrapper for some streams

We should probably fix this in async-std directly, or point folks indeed to io_arc. Regardless it may be worthwhile to allow people to pass a generic stream since people may, for example, want to create a custom TLS setup and not want to go through the motions of interacting with the Server trait. Having a way to just pass any stream is an escape hatch worth adding.

I'm not necessarily opposed to adding this method, but I wonder if we have a way to pass arbitrary streams whether having a unix-specific method would still be worth it. Especially if we also add Clone to async_std::os::unix::UnixStream. I'd prefer if we started with the more generic approach first, and then re-evaluate whether this method still makes sense later.

[jbr]

Agreed about the async-std unixstream clone thing. Also, I started in on a branch locally trying to get tls working with this stuff, but it's not quite compiling yet. It's been a few days but I believe that also needed some wrapper stuff to make it Clone.

Further considerations:

Somewhere something needs to set peer_addr and local_addr for each RW -> Request conversion, and currently that's not taken into consideration on this branch. There might need to be some explicit trait for these Read+Write+Unpin+Clone etc that also includes methods for that (with implementations for TcpStream and UnixStream). Or something along those lines?

I also was thinking that it would be nice to provide an even-higher level dispatch for these, that takes a string which either starts with tcp://{socketaddr}, unix:{path}, or whatever the windows equivalent would be, again with the idea that 12-factor type deployments might want to configure whether it's listening on a tcp port or a unix socket through an env var without recompiling. Similarly, tide might want to make it easy to a CLI server of some sort that accepts a --bind option with a similar format. The reference I was looking at when I was thinking about this was puma

[jbr]

I wrote up a very rough idea of what I meant regarding a trait that includes the Read+Write bounds and also allows an external type to configure peer and local addrs or anything else on the request (such as potentially adding custom local/extension typemap stuff): https://github.com/jbr/http-service/blob/do-not-merge-unix-socket-example/http-service-h1/src/lib.rs#L27-L57

[jbr]

Related PR for async-std to make UnixStream Clone: async-rs/async-std#772

[jbr]

closing in preference to the newer #531