TLS server support?

[fluffysquirrels]

The guide doesn't mention TLS server support, which I would argue is an important feature for many users. I realise that third-party crates are required to support TLS with hyper, but how about linking to some of them or providing an example to make it a bit easier for new users to find? For comparison, TLS configuration is mentioned for the hyper client and there is a link to hyper-tls

Similar to how reqwest is mentioned in the hyper README.md as a high-level easy-to-use wrapper over the hyper client, is it intended for higher-level server frameworks like warp to be easy-to-use wrappers over the hyper server that provide TLS? In which case how about linking to some or even to the Web Development Frameworks page on arewewebyet.org

Would you accept a PR for this?

[seanmonstar]

Good point!

Perhaps the hyper-tls crate should provide a hyper::server::Accept implementation for easy usage, and then we can show how to easily use it to get up and running, and describe how one could pick a different TLS implementation if desired. What do you think of that?

[fluffysquirrels]

Seems like a good plan to me. I can work on an Accept implementation in hyper-tls and hyper-rustls.

[fluffysquirrels]

I wrote a server example for hyper-tls that uses hyper::server::accept::from_stream and is quite short: https://github.com/fluffysquirrels/hyper-tls/blob/server-example/examples/server.rs. Do you think it's worth extracting something from that into the hyper-tls lib, and if so what :) ? Perhaps a fn(TcpListener, tokio_tls::TlsAcceptor) -> impl hyper::server::accept::Accept?

hyper-rustls had a similar example already, which I worked from. I could write a PR to use hyper::server::accept::from_stream and trim down their example a bit. Thoughts?

[Arlen22]

It's really easy to get started climbing Mount Everest! All you have to do is book a commercial flight to the nearest international airport. I just got done going through the walkthrough demonstrating HTTP2, and the second I realized I hadn't been told to use a server cert and key anywhere I just about gave up.

I'm not looking for an implementers proof of concept marketed to someone looking to spin their own TLS. We all know encryption isn't supposed to be DIY, so there should be at most 3 libraries to choose from when it comes to using hyper with HTTPS.

So if you don't have your 3 libraries yet, then this getting started guide makes sense, because you need it to market to your third-party library implementers to show them how easy it would be to create a server they can wrap in TLS.

I definitely don't know enough about HTTP2 to know what this proof of concept even proves. If I can't accept HTTP2 connections from the browser, then I have no idea what I'm looking at. Does the listener loop return a TCP stream or an individual HTTP2 session request stream? I don't see a headers object like I would see in node, so I'm assuming this is a TCP stream, but the getting started guide doesn't say anything about this.

Ok, to be fair, this setup does make sense if I want to bring multiple listener's tcp streams into one http2 session manager, but the session manager is pretty tightly integrated into the TLS handshake, isn't it? Now I'm having to guess or try to figure out how I'm supposed to implement HTTP2, which is exactly what w3.org was trying to avoid by make the http2 spec so tight and specific. If you're going to market this to everyone, implementing TLS is absolutely essential, otherwise you should probably replace the guides with a page that says "We don't intend you to use this in your application directly. Instead, here is a list of production ready implementations which use our stack."

let (stream, _) = listener.accept().await?;
let io = TokioIo::new(stream);
http2::Builder::new(TokioExecutor)
  .serve_connection(io, 
    service_fn(echo) //if stream is a TCP stream, then HTTP2 session handling occurs here and calls echo for each session stream?
  ).await