eccf90a534
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. |
||
|---|---|---|
| .. | ||
| end.cert | ||
| end.chain | ||
| end.rsa | ||
| test.rs | ||