Hyper-tls: How can use hyper-tls for server

[uncotion]

Hi,
Is it possible use hyper-tls for hyper server "0.12" ?

[seanmonstar]

Not really... But I'd welcome adding some API to ease this!

[jbaublitz]

@seanmonstar I was just about to open a similar issue for this. As you're looking for a PR, do you have preferences around what this API would look like or should I submit the PR and review it then?

[seanmonstar]

I haven't thought much about it, if you want to suggest something now, I can comment, or we can just review in a PR.

[jbaublitz]

@seanmonstar My initial thoughts are, for starters, to provide From implementations from native_tls::TlsStream to hyper_tls::TlsStream and hyper_tls::MaybeHttpsStream. Even that would suffice for usage in the Server struct I type parameter based on the traits that both hyper_tls structs implement. The user could at least that way handle all of the certificate/socket address creation through native_tls. I'm looking at this as a first step as this is kind of a blocker for me right now. I think there's room for improvements and abstractions later on but this feels like a good "get this working" step for now. Does that sound good? If so, I'll start on a PR.

[seanmonstar]

Sure!

[jbaublitz]

PR #28 created. Lemme know if you have any feedback there. Thanks!

[jbaublitz]

I've gotten a working example with MaybeHttpsStream. It definitely needs some work as it is currently very verbose. Should I post my findings here or open a new issue?

[jbaublitz]

@uncotion Here is a working example of a TLS server using the updated From trait additions.

[jonhere]

One approach is implementing the trait hyper::server::accept::Accept (note now hyper 0.13, can't comment on any api changes.)
I wrote this (part of working prototype) before coming to this issue.
If I was going to go further, would probably make it generic over Accept in particular taking/using hyper::server::conn::AddrIncoming.
(To finish add polish extension traits for better integration.)

[timbru]

I see that Warp has an implementation of all this. Would it be an option to move that implementation here?

[seanmonstar]

@timbru sort of! Warp uses rustls, while this crate is currently using native-tls. However, it'd be a fine place to start, and just adapt to the native-tls types.

[timbru]

@seanmonstar do you mean that it should use native-tls directly? Or could it be built on existing work in tokio-tls? I need to do more research - I am fairly new to this - but it seems to implement a lot of what is needed, and it's already a dependency.