✓ Uses Rust 2018 edition
|0.4.0||May 17, 2020|
|0.3.2||Jan 3, 2020|
|0.2.1||Jan 1, 2020|
|0.2.0||May 26, 2019|
|0.1.8||Jun 17, 2017|
#12 in #tls
921 downloads per month
Used in 2 crates
- tls-api — TLS API without any implementation and without dependencies
- tls-api-native-tls — implementation of TLS API over native-tls crate
- tls-api-openssl — implementation of TLS API over openssl crate
- tls-api-rustls — implementation of TLS API over rustls crate
- tls-api-schannel — missing implementation of TLS API over schannel crate
- tls-api-security-framework — missing implementation of TLS API over security framework crate
- tls-api-stub — stub API implementation which returns an error on any operation
If you develop a library, you do not know which TLS library your user would like to use, and if they need any TLS library at all.
Because of that some libraries simply depend on specific TLS implementations, while others provide "features" to turn on specific dependencies.
It makes development for both library authors and library users inconvenient. Both authors and users need to configure "features" in
#[cfg] in code. For example, your library need to support three options: use openssl, use native-tls, and no TLS at all. So you need to compile your library three times to check it can be compiled properly with all three options.
Library authors simply write the code with tls-api library. Since
tls-api is lightweight, library authors can simply write code using it, and have no configuration options.
Library users simply call that library with different implementations of connectors and acceptors.
api-test contains tests implementation independent of any library. And identical tests which use:
|Can fetch google.com:443||Yes||Yes||Yes|
native-tls uses security-framework on OSX, and security-framework does not support ALPN.
Or you simply want to have an option to avoid building TLS library.