Libcurl expects that headers are iterated in the same order that they
are recieved. Previously this caused curl tests 580 and 581 to fail.
This necessitated exposing a way to preserve the original ordering of
http headers.
SUMMARY OF CHANGES: Add a new data structure called OriginalHeaderOrder that
represents the order in which headers originally appear in a HTTP
message. This datastructure is `Vec<(Headername, multimap-index)>`.
This vector is ordered by the order which headers were recieved.
Add the following ffi functions:
- ffi::client::hyper_clientconn_options_set_preserve_header_order : An
ffi interface to configure a connection to preserve header order.
- ffi::client::hyper_clientconn_options_set_preserve_header_case : An
ffi interface to configure a connection to preserve header case.
- Add a new option to ParseContext, and Conn::State called `preserve_header_order`.
This option, and all the code paths it creates are behind the `ffi`
feature flag. This should not change performance of response parsing for
non-ffi users.
Closes#2780
BREAKING CHANGE: hyper_clientconn_options_new no longer
sets the http1_preserve_header_case connection option by default.
Users should now call
hyper_clientconn_options_set_preserve_header_case
if they desire that functionality.
The client now has an option to allow parsing responses with obsolete line folding in headers. The option is off by default, since the spec recommends to reject such things if you can.
This value is like a high-water mark. It applies per stream. Once a
stream has buffered that amount of bytes to send, it won't poll more
data from the `HttpBody` until the stream has been able to flush under
it.
These options are currently available on the high-level builder only.
Along the way, rename the setters to follow the public API conventions
and add docs.
Closes#2461
Note the practical affects of this change:
- Dependency count with --features full dropped from 65 to 55.
- Time to compile after a clean dropped from 48s to 35s (on a pretty underpowered VM).
Closes#2388
Decouple preserving header case from FFI:
The feature is now supported in both the server and the client
and can be combined with the title case feature, for headers
which don't have entries in the header case map.
Closes#2313
* refactor: Use async/await in client.rs
* refactor: Simplify client.rs a bit more
* refactor: Allow !Unpin in Lazy
* Remove some impl Future
* Remove some combinator use
Add basic, module level example for the Builder performing a handshake,
spawning a task to run the Connection and sending a single request and
receiving the response.
Closes#2272
Tokio's `AsyncWrite` trait once again has support for vectored writes in
Tokio 0.3.4 (see tokio-rs/tokio#3149).
This branch re-enables vectored writes in Hyper for HTTP/1. Using
vectored writes in HTTP/2 will require an upstream change in the `h2`
crate as well.
I've removed the adaptive write buffer implementation
that attempts to detect whether vectored IO is or is not available,
since the Tokio 0.3.4 `AsyncWrite` trait exposes this directly via the
`is_write_vectored` method. Now, we just ask the IO whether or not it
supports vectored writes, and configure the buffer accordingly. This
makes the implementation somewhat simpler.
This also removes `http1_writev()` methods from the builders. These are
no longer necessary, as Hyper can now determine whether or not
to use vectored writes based on `is_write_vectored`, rather than trying
to auto-detect it.
Closes#2320
BREAKING CHANGE: Removed `http1_writev` methods from `client::Builder`,
`client::conn::Builder`, `server::Builder`, and `server::conn::Builder`.
Vectored writes are now enabled based on whether the `AsyncWrite`
implementation in use supports them, rather than though adaptive
detection. To explicitly disable vectored writes, users may wrap the IO
in a newtype that implements `AsyncRead` and `AsyncWrite` and returns
`false` from its `AsyncWrite::is_write_vectored` method.
cc #2223
BREAKING CHANGE: The HTTP client of hyper is now an optional feature. To
enable the client, add `features = ["client"]` to the dependency in
your `Cargo.toml`.
cc #2251
BREAKING CHANGE: This puts all HTTP/1 methods and support behind an
`http1` cargo feature, which will not be enabled by default. To use
HTTP/1, add `features = ["http1"]` to the hyper dependency in your
`Cargo.toml`.
cc #2251
BREAKING CHANGE: This puts all HTTP/2 methods and support behind an
`http2` cargo feature, which will not be enabled by default. To use
HTTP/2, add `features = ["http2"]` to the hyper dependency in your
`Cargo.toml`.
Previously, calling `http1_writev(true)` would just keep the default behavior, which was to auto detect if writev was optimal. Now, the auto-detection is still default, but explicitly calling `http1_writev(true)` will skip the auto-detection, and always use writev queue strategy.
Closes#2282
This adds HTTP2 keep-alive support to client and server connections
based losely on GRPC keep-alive. When enabled, after no data has been
received for some configured interval, an HTTP2 PING frame is sent. If
the PING is not acknowledged with a configured timeout, the connection
is closed.
Clients have an additional option to enable keep-alive while the
connection is otherwise idle. When disabled, keep-alive PINGs are only
used while there are open request/response streams. If enabled, PINGs
are sent even when there are no active streams.
For now, since these features use `tokio::time::Delay`, the `runtime`
cargo feature is required to use them.
This adds support for calculating the Bandwidth-delay product when using
HTTP2. When a DATA frame is received, a PING is sent to the remote.
While the PING acknoledgement is outstanding, the amount of bytes of all
received DATA frames is accumulated. Once we receive the PING
acknowledgement, we calculate the BDP based on the number of received
bytes and the round-trip-time of the PING. If we are near the current
maximum window size, the size is doubled.
It's disabled by default until tested more extensively.
