Commit Graph

11 Commits

Author SHA1 Message Date
Joseph Birr-Pixton
a8e1e9ac35 Fix warnings now set_single_cert yields a Result 2018-07-15 15:02:42 +01:00
quininer
fff2f4a73b fix(tokio_impl): shutdown WouldBlock 2018-03-31 15:16:31 +08:00
quininer
1820868929 fix: futures_impl 2018-03-23 17:31:55 +08:00
quininer
64ca6e290c change: use rustls Stream 2018-03-23 17:14:27 +08:00
quininer
d4cb46e895 feat: start futures_impl 2018-03-22 19:47:27 +08:00
quininer
8c79329c7a feat: split tokio_impl/futures_impl 2018-03-21 13:08:47 +08:00
quininer
9f78454cf1 feat: try futures 0.2 2018-03-20 20:17:44 +08:00
quininer
8d6140a7b9 upgrade example/test to tokio 2018-02-28 14:36:37 +08:00
Brian Smith
51ed8da9cb Update to in-progress Rustls, webpki, and webpki-roots.
Use the new, less error-prone, API in Rustls.
2017-09-03 13:00:42 -10:00
Brian Smith
eccf90a534 Remove danger feature & the API it controls.
The singular purpose of this crate should be to integrate Tokio and
Rustls. Therefore, any feature that isn't about making Rustls work
nicely with Tokio should be assumed a priori to be out of scope.

In particular, it is out of scope for tokio-rustls to provide APIs to
control SNI behavior. Instead, the application should configure
Rustls's SNI behavior using Rustls's configuration APIs, and pass the
configuration to tokio-rustls. Similarly, it is out of scope for
tokio-rustls to provide APIs to control the certificate validation
behavior. Instead, the application should configure certificate
validation using Rustls's APIs. Perhaps there should be a crate that
makes it convenient to do "dangerous" certificate validation, but IMO
that shouldn't be tokio-rustls, but a different one.

FWIW, the `danger` API was inherited from tokio-tls, and I'm working on
making an analogous change there.
2017-08-28 18:43:33 -10:00
quininer
037f84ea98 [Added] tests 2017-08-13 18:48:30 +08:00