reqwest-boring is a fork of the original reqwest HTTP client by Sean McArthur and contributors. It replaces the default TLS layer with boring, the Rust bindings to BoringSSL, and uses Quiche for HTTP/3.
The package is published as reqwest-boring; the Rust library remains named reqwest. Existing client, request, response, and builder APIs are preserved, with the backend-specific configuration difference documented below.
- Async and blocking
Clients - Plain bodies, JSON, urlencoded, multipart
- Customizable redirect policy
- HTTP Proxies
- HTTPS via BoringSSL (or optionally, system-native TLS)
- HTTP/3 via Quiche, sharing the same BoringSSL build
- Cookie Store
- WASM
This asynchronous example uses Tokio and enables some
optional features, so your Cargo.toml could look like this:
[dependencies]
reqwest = { package = "reqwest-boring", version = "0.13.5", features = ["json"] }
tokio = { version = "1", features = ["full"] }And then the code:
use std::collections::HashMap;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let resp = reqwest::get("https://httpbin.org/ip")
.await?
.json::<HashMap<String, String>>()
.await?;
println!("{resp:#?}");
Ok(())
}The default TLS backend uses boring and tokio-boring. Building BoringSSL requires a C/C++ compiler, CMake, Perl, and libclang (for bindgen). On Windows, install LLVM and NASM as well. HTTP/3 uses quiche with boringssl-boring-crate, so it links the same BoringSSL library. Enable it with features = ["http3"] and RUSTFLAGS="--cfg reqwest_unstable".
Windows ARM64 builds of BoringSSL 4.x need its portable C implementation. Set CMAKE_TOOLCHAIN_FILE to the absolute path of a CMake file containing set(OPENSSL_NO_ASM ON CACHE BOOL "Use portable BoringSSL" FORCE), as in the CI toolchain file.
For 32-bit Windows GNU, use a 32-bit libclang with a 32-bit Rust host. Set CFLAGS_i686_pc_windows_gnu, CXXFLAGS_i686_pc_windows_gnu, and BINDGEN_EXTRA_CLANG_ARGS_i686_pc_windows_gnu to -D_USE_32BIT_TIME_T so BoringSSL and its generated bindings match Rust's time_t ABI.
The rustls and rustls-no-provider features and the tls_backend_rustls() / use_rustls_tls() builder methods remain compatibility aliases for BoringSSL. A Rustls crypto provider is no longer needed. tls_backend_preconfigured() / use_preconfigured_tls() keep their signatures but accept boring::ssl::SslConnector in place of Rustls configuration objects; this backend-specific escape hatch has no upstream semver guarantee. Configure HTTP/3 through the standard builder methods.
Apple platforms use Security.framework to validate system trust; Windows loads the system root store, and other native platforms use system CA files. Custom certificates, PEM client identities, certificate revocation lists, TLS versions, SNI, key logging, and TLS metadata remain available through the existing API.
Browser WASM targets use the browser's TLS implementation.
The optional native-tls backend uses the system TLS framework on Windows and Apple platforms. On Linux and other native targets, native-tls features (including native-tls-vendored) and the tls_backend_native() / use_native_tls() methods are compatibility aliases for BoringSSL. This avoids incompatible OpenSSL and BoringSSL symbols in the same process. PKCS#12 and PKCS#8 client identities remain supported. Preconfigured native-tls connectors are supported only on Windows and Apple platforms; use boring::ssl::SslConnector elsewhere.
This fork builds on the original reqwest project by Sean McArthur and its contributors. The upstream MIT and Apache-2.0 licenses and copyright notices are retained. Fork-specific issues and contributions belong in madeye/reqwest-boring.
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or http://apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.