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.
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
dangerAPI was inherited from tokio-tls, and I'm working on making an analogous change there.