A generic async HTTP request create.

It is meant to be a thin wrapper around various HTTP clients and handles TLS, serialization and parsing.

The main goal is to allow binaries (that pull in some libraries that make use of a HTTP client) to specify what implementation should be used.

And if there is a Proxy. If not specified auto detection is performed by looking at HTTP_PROXY.

Features

You need to specify via features what crates are used to do the actual work.

feature flag	Meaning
use_hyper	Use hyper for HTTP
use_async_h1	Use async_h1 for HTTP
rustls	Add support for HTTPS via rustls
proxies	Add support for Socks5 and HTTP proxy
hyper_native_tls	Use hyper for HTTP and do HTTPS via native_tls
async_native_tls	Use async_h1 for HTTP and do HTTPS via native_tls

Without anything specified you will end up with No HTTP backend was selected. If you use this crate for a library, please reexport the appropriate features.

Motivation

Rust offers different async runtimes that - on a high level - offer the same thing: asynchronous functions for files, sockets and so on.

So if you write a lib and need some basic stuff (like an http client) you sometimes have to make choices that are not what your crates users would have liked. For example: I wrote a webserver based on hyper and wanted to add ACME. A crate I found did what I needed but used async-h1 and async-std. While that worked, it did increase the binary size and crates I depend on by a good amount.

So I wrote this. You can specify which backend to use. In the Webserver case, using tokio which is already a dependency VS async-std did lead to 81 less crates and a 350kB smaller binary. Using (and async-acme):

[profile.release]
lto = "fat"
codegen-units = 1

Also for http clients: there should be a way to add a proxy for all libs that use it.

Plans

2. Add Sessions - to make multiple requests more efficient
3. Add a cookie jar for the sessions
4. Allow a Body to be streamed from a server
5. Allow a Body to be streamed to a server