-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Allow swapping out native-tls for rustls #63
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -32,16 +32,23 @@ pub struct Client { | |
|
||
impl Client { | ||
/// Constructs a new `Client`. | ||
#[cfg(feature = "default-tls")] | ||
pub fn new() -> ::Result<Client> { | ||
let mut client = try!(new_hyper_client()); | ||
client.set_redirect_policy(::hyper::client::RedirectPolicy::FollowNone); | ||
Ok(Client { | ||
Ok(Client::with_hyper_client(client)) | ||
} | ||
|
||
/// Constructs a new `Client` with the provided `::hyper::Client` without | ||
/// altering any settings. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this be promised? Specifically I'm thinking about the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't know to be honest. I was considering a note like "if you use this method, you should look at the source of reqwest to create a client that's configured the same way as reqwest is expecting". My main question is whether someone will someday want to use the hyper redirect policy rather than the reqwest one - what happens then? Or some other method on hyper that reqwest wants to set a default for (e.g. reqwest wants to start configuring timeouts and wants to set a different default value to hyper)? How about I that "this method will configure your hyper::Client to use the reqwest default settings", and then if someone doesn't want that then they can make a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess the provided client should be left alone, then. I wouldn't want an extra |
||
pub fn with_hyper_client(client: ::hyper::Client) -> Client { | ||
Client { | ||
inner: Arc::new(ClientRef { | ||
hyper: client, | ||
redirect_policy: Mutex::new(RedirectPolicy::default()), | ||
auto_ungzip: AtomicBool::new(true), | ||
}), | ||
}) | ||
} | ||
} | ||
|
||
/// Enable auto gzip decompression by checking the ContentEncoding response header. | ||
|
@@ -112,6 +119,7 @@ struct ClientRef { | |
auto_ungzip: AtomicBool, | ||
} | ||
|
||
#[cfg(feature = "default-tls")] | ||
fn new_hyper_client() -> ::Result<::hyper::Client> { | ||
use hyper_native_tls::NativeTlsClient; | ||
Ok(::hyper::Client::with_connector( | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh boy, flashbacks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is a hint that you're expecting this change to not be present!
I'll clarify - the main motivation for this PR for me is to remove the dependency on openssl, so above all else I need to make hyper-native-tls optional. Of course, this has knock-on effects - if I remove hyper-native-tls, I need another way to support tls (i.e. hyper-rustls).
Fortunately, making hyper-native-tls optional works fine under the additive model (which I didn't really know about, so thanks for mentioning it) - if one consumer doesn't require hyper-native-tls, the way it constructs a reqwest client is totally independent of whether hyper-native-tls is actually present or not, since it uses a completely different function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, not objecting really. Just remembering the joys of when TLS was optional in hyper...
I do kind of wish this was pushed for instead in the native-tls repo, so that native-tls resorts to rustls on Linux instead of OpenSSL...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me think about what it would take to get this into native-tls instead (perhaps as a feature, rather than by default). It would potentially push the problem down the road (e.g. complex proxy configurations), but those might be better handled as first-class citizens in reqwest anyway, and rustls would be useful to have in native-tls anyway.