mirror of
https://github.com/curl/curl.git
synced 2024-12-21 06:50:10 +08:00
b9b50f3193
The current design of the Hyper integration requires rebuilding the Hyper clientconn for each request. However, building the clientconn requires resending the HTTP/2 connection preface, which is incorrect from a protocol perspective. That in turn causes servers to send GOAWAY frames, effectively degrading performance to "no connection reuse" in the best case. It may also be triggering some bugs where requests get dropped entirely and reconnects take too long. This doesn't rule out HTTP/2 support with Hyper, but it may take a redesign of the Hyper integration in order to make things work. Closes #12191
74 lines
2.4 KiB
Markdown
74 lines
2.4 KiB
Markdown
# 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
|
|
happen in the master branch using pull-requests, just like ordinary
|
|
changes.
|
|
|
|
## Hyper version
|
|
|
|
The C API for Hyper is brand new and is still under development.
|
|
|
|
## build curl with hyper
|
|
|
|
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
|
|
|
|
# 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.
|
|
|
|
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.
|
|
|
|
## Limitations
|
|
|
|
The hyper backend does not support
|
|
|
|
- `CURLOPT_IGNORE_CONTENT_LENGTH`
|
|
- `--raw` and disabling `CURLOPT_HTTP_TRANSFER_DECODING`
|
|
- RTSP
|
|
- hyper is much stricter about what HTTP header contents it allows
|
|
- leading whitespace in first HTTP/1 response header
|
|
- HTTP/0.9
|
|
- HTTP/2 upgrade using HTTP:// URLs. Aka 'h2c'
|
|
- 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.
|
|
|
|
## 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
|