TLS server support? #46

Activity

1. seanmonstar commented on Nov 25, 2019

   

   seanmonstar

   on Nov 25, 2019

   Member

   More actions

   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?
2. fluffysquirrels commented on Nov 26, 2019

   

   fluffysquirrels

   on Nov 26, 2019

   Author

   More actions

   Seems like a good plan to me. I can work on an Accept implementation in hyper-tls and hyper-rustls.
3. fluffysquirrels commented on Nov 28, 2019

   

   fluffysquirrels

   on Nov 28, 2019

   Author

   More actions

   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?
4. Arlen22 commented on Jan 19, 2025

   

   Arlen22

   on Jan 19, 2025

   Last edited by Arlen22

   More actions

   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
   

   😕React with 😕1Reacted by Sean McArthur