feat(server): Add an ssl example

[trezm]

Adds an example using hyper + ssl for a server.

Should resolve the closed issue #1942

[shirshak55]

any reason to change 100644 → 100755 ?

[trezm]

Totally, not sure why/how the permissions go changed on these files! Updated accordingly.

[Darkspirit]

https://github.com/ctz/hyper-rustls/blob/master/examples/server.rs

[trezm]

Note: I think this might currently be broken due to this change: 71d088d, at least until tokio updates their dependencies to future 0.3.1 as well.

@Darkspirit that's awesome!! If you'd like to replace this with an example from that repo that'd be great. It just seems like for such a simple setup there should be an example to point people towards if they happen to want to have SSL on their server.

[Darkspirit]

Thank you for trying to merge a tls server example at all! :) I would be very grateful if you could update this pull request to use (the well received) rustls instead of non-rusty native-tls. Rustls and its dependencies webpki and ring are for example used by time.cloudflare.com, Google Fuchsia and Baidu. (Ring is based on Boringssl, Google's improved fork of OpenSSL, but got lots of C and C++ replaced with Rust.) It's quite sad that native-tls is spreading a bit like cancer, especially because it doesn't use Rust at places where its safety guarantees are most useful.

[trezm]

Oh totally! Wasn't even aware of the differences/benefits!! Always happier to use the rusty alternative anyway!

…

On Sat, Nov 16, 2019, 9:40 AM Darkspirit ***@***.***> wrote: Thank you for trying to merge a tls server example at all! :) I would be very grateful if you could update this pull request to use (the well received) rustls instead of non-rusty native-tls. Rustls and its dependencies webpki and ring are for example used by time.cloudflare.com, Google Fuchsia and Baidu. (Ring is based on Boringssl, Google's improved fork of OpenSSL, but got lots of C and C++ replaced with Rust.) It's quite sad that native-tls is spreading a bit like cancer, especially because it doesn't use Rust at places where its safety guarantees are most useful. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1990?email_source=notifications&email_token=AAJWOLP4HNXGC7AZC55GEELQUAA4RA5CNFSM4JDKM6IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHS6YI#issuecomment-554643297>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJWOLNU3TEJ6EBS22UA373QUAA4RANCNFSM4JDKM6IA> .

[trezm]

Checking back in on this -- I have a PR open to the tokio-tls repo to add rustls as a tls option. That being said, it looks like that might take a while to get in, which is unfortunate.

While experimenting though, I also noticed that the way the code is currently written, a long-lived http call will block request execution. Does anyone have any ideas around this? Basically because filter_map does not continue accepting sockets, we would need a stream op that always takes the next item and forms a new stream whose order is based on the completion time of an async closure run on each element of the original stream.

[twe4ked]

This looks awesome, it would be great to have an SSL example in the repo. I've had a search around an most of the examples I found of SSL/hyper are outdated because the async code has been moving so fast. Any updates on this?

[trezm]

I'll try to get back on this now that https://github.com/tokio-rs/tls is a real thing!

…

On Thu, Mar 12, 2020 at 8:22 PM Odin Dutton ***@***.***> wrote: This looks awesome, it would be great to have an SSL example in the repo. I've had a search around an most of the examples I found of SSL/hyper are outdated because the async code has been moving so fast. Any updates on this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1990 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJWOLKKGH6QTSOW3REA76TRHF4EHANCNFSM4JDKM6IA> .

[seanmonstar]

Thanks for the PR! I'd rather not include examples in the hyper repo selecting specific TLS libraries. I think something like this could be part of hyper-tls, once it gains a server API.