Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

thoughts on a compiler feature flagged default tls connector #1312

Closed
softprops opened this issue Sep 8, 2017 · 6 comments
Closed

thoughts on a compiler feature flagged default tls connector #1312

softprops opened this issue Sep 8, 2017 · 6 comments

Comments

@softprops
Copy link
Contributor

Hyper is the defacto std for http interaction in rust, hands down. However my main disappointment is that for every time I use it in a crate I need to do the following in every crate that uses it.

...
use hyper_tls::HttpsConnector;
...

 let mut core = Core::new()?;
 let client = hyper::Client::configure()
            .connector(HttpsConnector::new(4, &core.handle())?)
            .build(&core.handle()).

I would be delighted to have a sane default selected for me now that the tokio/tls crate ecosystem is stabilizing. I understand that reqwest exists and that having a default would require additional maintenance on behavior of hyper tracking the tls crates changes but for something so fundamental for http interaction with modern web apis, not being about to request https urls out of the box with the default standard for working with http in the rust ecosystem can be embarrassing when trying to turn others on to the wonders of rust.

The reason I opt for depending on hyper rather than request is that I like keeping my dependencies to a minimum because im using building clients for apis to use in other crates and I want to reduce the dependency surface area they have to bring in to use my crate.

I wanted to hear your thoughts on if continuing to not support https out of the box is a strong stance or if there was just a hold over period while the tokio/tls crate situation stabilized. In particular perhaps this can be a default enabled by default but can be opted out of with a compiler flag.

note: I'm aware that technically removing the tls default was a change made in 0.10 and that the tls default in the past mainly caused issues for other reasons because of the openssl native bindings.

@jimmycuadra
Copy link

This would make sense once we have a 1.0, audited, pure-rust implementation of TLS (presumably rustls, but could be something else by the time it happens.) My understanding is that the reason there's no default now is because there simply isn't a cross-platform option that makes sense right now. In other languages, they either assume/require OpenSSL (e.g. Ruby), or have a vetted native TLS implementation (e.g. Go).

@softprops
Copy link
Contributor Author

Makes sense. Thanks for the response!

@softprops
Copy link
Contributor Author

@jimmycuadra I just realized who you were! I just today took some inspiration from your etcd crate on how to use cargo feature to add a optional default tls impl https://github.com/jimmycuadra/rust-etcd/blob/master/Cargo.toml

@jimmycuadra
Copy link

Glad to be of help! I have no authority on hyper, BTW, so you might want to reopen your issue for more discussion. I was just adding my thoughts. :}

@softprops
Copy link
Contributor Author

I was mainly looking on for some direction for some ergonomic solutions but I think I found the perfect example in your crate :)

@seanmonstar
Copy link
Member

Additionally, to read the write-up on why SSL was removed, see #985. It really describes all the issues, and why the decision was made.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants