2020-12-14 21:10:32 +08:00
|
|
|
# Hyper
|
|
|
|
|
|
|
|
Hyper is a separate HTTP library written in Rust. curl can be told to use this
|
|
|
|
library as a backend to deal with HTTP.
|
|
|
|
|
|
|
|
## Experimental!
|
|
|
|
|
|
|
|
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 will
|
2022-10-26 14:59:35 +08:00
|
|
|
happen in the master branch using pull-requests, just like ordinary
|
2020-12-14 21:10:32 +08:00
|
|
|
changes.
|
|
|
|
|
|
|
|
## Hyper version
|
|
|
|
|
2021-05-29 05:06:19 +08:00
|
|
|
The C API for Hyper is brand new and is still under development.
|
2020-12-14 21:10:32 +08:00
|
|
|
|
|
|
|
## build curl with hyper
|
|
|
|
|
2023-08-12 04:18:19 +08:00
|
|
|
Using Rust 1.64.0 or later, build hyper and enable its C API like this:
|
2020-12-14 21:10:32 +08:00
|
|
|
|
2021-01-09 06:54:22 +08:00
|
|
|
% git clone https://github.com/hyperium/hyper
|
2020-12-14 21:10:32 +08:00
|
|
|
% cd hyper
|
2023-08-12 04:18:19 +08:00
|
|
|
% RUSTFLAGS="--cfg hyper_unstable_ffi" cargo rustc --features client,http1,http2,ffi --crate-type cdylib
|
2020-12-14 21:10:32 +08:00
|
|
|
|
2023-08-11 14:47:21 +08:00
|
|
|
Also, `--release` can be added for a release (optimized) build.
|
|
|
|
|
2020-12-14 21:10:32 +08:00
|
|
|
Build curl to use hyper's C API:
|
|
|
|
|
|
|
|
% git clone https://github.com/curl/curl
|
|
|
|
% cd curl
|
2022-05-02 23:52:16 +08:00
|
|
|
% autoreconf -fi
|
2023-08-11 14:47:21 +08:00
|
|
|
% ./configure LDFLAGS="-Wl,-rpath,<hyper-dir>/target/debug -Wl,-rpath,<hyper-dir>/target/release" --with-openssl --with-hyper=<hyper-dir>
|
2020-12-14 21:10:32 +08:00
|
|
|
% make
|
|
|
|
|
|
|
|
# using Hyper internally
|
|
|
|
|
|
|
|
Hyper is a low level HTTP transport library. curl itself provides all HTTP
|
|
|
|
headers and Hyper provides all received headers back to curl.
|
|
|
|
|
2021-01-08 04:11:17 +08:00
|
|
|
Therefore, most of the "header logic" in curl as in responding to and acting
|
2020-12-14 21:10:32 +08:00
|
|
|
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.
|
2021-01-02 18:42:27 +08:00
|
|
|
|
2021-06-03 23:56:36 +08:00
|
|
|
## Limitations
|
|
|
|
|
2021-10-31 23:34:44 +08:00
|
|
|
The hyper backend does not support
|
2021-06-03 23:56:36 +08:00
|
|
|
|
|
|
|
- `CURLOPT_IGNORE_CONTENT_LENGTH`
|
2021-10-22 14:44:14 +08:00
|
|
|
- `--raw` and disabling `CURLOPT_HTTP_TRANSFER_DECODING`
|
2021-06-03 23:56:36 +08:00
|
|
|
- RTSP
|
2022-03-20 06:12:03 +08:00
|
|
|
- hyper is much stricter about what HTTP header contents it allows
|
2023-08-07 18:45:45 +08:00
|
|
|
- leading whitespace in first HTTP/1 response header
|
2021-10-26 23:26:21 +08:00
|
|
|
- HTTP/0.9
|
2022-03-20 06:12:03 +08:00
|
|
|
- HTTP/2 upgrade using HTTP:// URLs. Aka 'h2c'
|
2023-10-24 22:51:05 +08:00
|
|
|
- HTTP/2 in general. Hyper has support for HTTP/2 but the curl side
|
|
|
|
needs changes so that a `hyper_clientconn` can last for the duration
|
|
|
|
of a connection. Probably this means turning the Hyper HTTP/2 backend
|
|
|
|
into a connection filter.
|
2021-06-03 23:56:36 +08:00
|
|
|
|
2021-01-02 18:42:27 +08:00
|
|
|
## Remaining issues
|
|
|
|
|
|
|
|
This backend is still not feature complete with the native backend. Areas that
|
|
|
|
still need attention and verification include:
|
|
|
|
|
|
|
|
- multiplexed HTTP/2
|
|
|
|
- h2 Upgrade:
|
|
|
|
- receiving HTTP/1 trailers
|
|
|
|
- sending HTTP/1 trailers
|