-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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). |
Makes sense. Thanks for the response! |
@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 |
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. :} |
I was mainly looking on for some direction for some ergonomic solutions but I think I found the perfect example in your crate :) |
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. |
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.
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.
The text was updated successfully, but these errors were encountered: