Hyper is a separate HTTP library written in Rust. curl can be told to use this library as a backend to deal with HTTP.
Hyper support in curl is considered EXPERIMENTAL until further notice. It needs to be explicitly enabled at build-time.
Further development and tweaking of the Hyper backend support in curl happens in the master branch using pull-requests, just like ordinary changes.
The C API for Hyper is brand new and is still under development.
Using Rust 1.64.0 or later, build hyper and enable its C API like this:
% git clone https://github.com/hyperium/hyper
% cd hyper
% RUSTFLAGS="--cfg hyper_unstable_ffi" cargo rustc --features client,http1,http2,ffi --crate-type cdylib
Also, --release
can be added for a release (optimized) build.
Build curl to use hyper's C API:
% git clone https://github.com/curl/curl
% cd curl
% autoreconf -fi
% ./configure LDFLAGS="-Wl,-rpath,<hyper-dir>/target/debug -Wl,-rpath,<hyper-dir>/target/release" --with-openssl --with-hyper=<hyper-dir>
% make
Hyper is a low level HTTP transport library. curl itself provides all HTTP headers and Hyper provides all received headers back to curl.
Therefore, most of the "header logic" in curl as in responding to and acting on specific input and output headers are done the same way in curl code.
The API in Hyper delivers received HTTP headers as (cleaned up) name=value pairs, making it impossible for curl to know the exact byte representation over the wire with Hyper.
The hyper backend does not support
CURLOPT_IGNORE_CONTENT_LENGTH
--raw
and disabling CURLOPT_HTTP_TRANSFER_DECODING
hyper_clientconn
can last for the duration
of a connection. Probably this means turning the Hyper HTTP/2 backend
into a connection filter.This backend is still not feature complete with the native backend. Areas that still need attention and verification include: