Extend Server to use anything that produces a stream of (Io, SocketAddr)

[mattwoodyard]

I've done some refactoring on Server to make it easier to integrate with and ssl listener.

[GitCop]

Thanks for contributing! Unfortunately, I'm here to tell you there were the following style issues with your Pull Request:

• Commit: 6cdf656

• Commits must be in the following format: %{type}(%{scope}): %{description}

• Commit: 80ae945

• Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/hyperium/hyper/blob/master/CONTRIBUTING.md

---

This message was auto-generated by https://gitcop.com

[seanmonstar]

Being generic over a stream of Ios was actually how the server used to work, and was changed to the current situation in #1013!

The idea is that Http implements ServerProto, and there is also the exposed bind_connection method, so really, any stream of connections can already be used.

Making use of TLS for the Server just involves using tokio_tls::proto::Server::new(http, listener), from here: https://github.com/tokio-rs/tokio-tls/blob/master/src/proto.rs

@alexcrichton may have more thoughts on the matter.

[mattwoodyard]

I tried getting that working first (https://play.rust-lang.org/?gist=d8d0d1ed14574f4085b1d663c6354ef8&version=stable&backtrace=0), but it seemed to be missing some implementation (I think: #1036). I was going to add that, but then I noticed that tokio-proto didn't have graceful shutdown, which is something I wanted, so I did this.

Is there something I've missed?

[alexcrichton]

@mattwoodyard sounds like you went down the same rabbit hole I did! @seanmonstar is spot on in that the server Hyper bundles isn't currently intended to be used with TLS (or other protocols for that matter). The idea is that protocols are built externally and then there's generic support for taking a protocol and spinning up a server with it.

Note, though, that support isn't quite here yet for all that. PRs like tokio-rs/tokio-proto#135 and issues like #1036 are key ingredients to getting that working. With #1036 Hyper's request/response should work "as-is" with tokio-proto's TcpServer and with tokio-rs/tokio-proto#135 then tokio-proto's TcpServer should reach feature parity with Hyper's current server in this repository.

@seanmonstar I'll leave it up to you whether you'd like to merge this for now. The intention at least is that this shouldn't be necessary (and in fact, the entire server shouldn't be necessary!), so you can at least rest easy that in the future you won't have to maintain this :)

[seanmonstar]

Oh right, what I had suggested doesn't actually work yet without #1036. With #1036 fixed, would that solve your use case @mattwoodyard?

[mattwoodyard]

For my immediate task, I'm just trying to get TLS to work. I'm not particularly attached to the approach in this PR. If #1036 can make the tokio_tls stuff work, thats fine. Longterm I'd like graceful shutdown with my TLS. If the plan is to generalize the hyper approach into tokio-proto, I can take a swing at that.

[alexcrichton]

Yeah I believe that's the general long term plan at least, to have Hyper work well with the tokio-proto server builders to leverage all of the logic in there (which will expand over time)

[mattwoodyard]

Closing in favor of #1047