+

+
+# Fetch Tls
+
+[](https://crates.io/crates/fetch_tls)
+[](https://docs.rs/fetch_tls)
+[](https://crates.io/crates/fetch_tls)
+[](https://github.com/microsoft/oxidizer/actions/workflows/main.yml)
+[](https://codecov.io/gh/microsoft/oxidizer)
+[](../../LICENSE)
+

+
+
+
+Backend-agnostic TLS configuration for HTTP clients.
+
+`fetch_tls` separates *what* TLS behavior an application wants from
+*which* TLS implementation actually provides it. Applications describe
+their TLS requirements once, and the HTTP client (or other consuming
+library) decides which backend to materialize at runtime.
+
+## Two perspectives
+
+Applications work with [`TlsOptions`][__link0] (and its builder,
+[`TlsOptionsBuilder`][__link1]) to describe what they want: leave the backend
+choice entirely to the consuming library via
+[`TlsOptions::builder`][__link2], pick a specific backend, wrap an already-built
+backend, or use [`TlsOptions::default`][__link3] for backend-agnostic defaults.
+
+Libraries that adopt `fetch_tls` use [`TlsBackendBuilder`][__link4] to turn a
+[`TlsOptions`][__link5] into a ready-to-use [`TlsBackend`][__link6]. The library
+contributes the environment-specific pieces (such as the rustls crypto
+provider and default certificate verifier) and decides which backend to
+use when the application did not pin one.
+
+## Cargo features
+
+* `rustls` — enables the rustls backend. `fetch_tls` does not bundle a
+ crypto provider; the consuming library supplies one along with a
+ default server certificate verifier.
+* `native-tls` — enables the platform native TLS backend (`SChannel` on
+ Windows, Security Framework on `macOS`, `OpenSSL` on Linux).
+
+With neither feature enabled, the API surface is limited to wrapping a
+pre-built backend; attempting to build any other configuration returns
+a [`BackendError`][__link7].
+
+
+