Change behaviour of connection or server response when the request is
version 1.0 and the Connection: keep-alive header is not present.
1. If the response is also version 1.0, then connection is closed if the
server keep-alive header is not present.
2. If the response is version 1.1, then the keep-alive header is added
when downgrading to version 1.0.
Closes#1614
If a user makes use of `Body::is_end_stream` to optimize so as to not
need to do make a final poll just to receive `None`, previously the
connection would not have progressed its reading state to a finished
body, and so the connection would be closed.
Now, upon reading any chunk, the connection state will check if it
can know that the body would be finished, and progresses to a body
finished state sooner.
The integration tests were amplified by adding a naive hyper proxy
as a secondary test, which happens to make use of that optimization,
and thus caught the issue.
- Adds `Body::on_upgrade()` that returns an `OnUpgrade` future.
- Adds `hyper::upgrade` module containing types for dealing with
upgrades.
- Adds `server::conn::Connection::with_upgrades()` method to enable
these upgrades when using lower-level API (because of a missing
`Send` bound on the transport generic).
- Client connections are automatically enabled.
- Optimizes request parsing, to make up for extra work to look for
upgrade requests.
- Returns a smaller `DecodedLength` type instead of the fatter
`Decoder`, which should also allow a couple fewer branches.
- Removes the `Decode::Ignore` wrapper enum, and instead ignoring
1xx responses is handled directly in the response parsing code.
Ref #1563Closes#1395
When getting a `Body` from hyper, such as in a client response,
the method `Body::content_length()` now returns a value if the header
was present.
Closes#1545
- In the higher-level `Server` API, since connection upgrades aren't yet
supported, returning a 2xx response to a `CONNECT` request is a user
error. A 500 response is written to the client, the connection is
closed, and an error is reported back to the user.
- In the lower-level `server::Connection` API, where upgrades *are*
supported, a 2xx response correctly marks the response as the final
one, instead of trying to parse more requests afterwards.
- When the `Body` is created from a buffer of bytes (such as
`Body::from("hello")`), we can skip some bookkeeping that is
normally required for streaming bodies.
- Orthogonally, optimize encoding body chunks when the strategy
is to flatten into the headers buf, by skipping the EncodedBuf
enum.
If an HTTP/1 connection has a parse error, but it starts with the HTTP2 preface, converts the connection automatically into an HTTP2 server connection.
Closes#1486
This introduces the `hyper::service` module, which replaces
`tokio-service`.
Since the trait is specific to hyper, its associated
types have been adjusted. It didn't make sense to need to define
`Service<Request=http::Request>`, since we already know the context is
HTTP. Instead, the request and response bodies are associated types now,
and slightly stricter bounds have been placed on `Error`.
The helpers `service_fn` and `service_fn_ok` should be sufficient for
now to ease creating `Service`s.
The `NewService` trait now allows service creation to also be
asynchronous.
These traits are similar to `tower` in nature, and possibly will be
replaced completely by it in the future. For now, hyper defining its own
allows the traits to have better context, and prevents breaking changes
in `tower` from affecting hyper.
Closes#1461
BREAKING CHANGE: The `Service` trait has changed: it has some changed
associated types, and `call` is now bound to `&mut self`.
The `NewService` trait has changed: it has some changed associated
types, and `new_service` now returns a `Future`.
`Client` no longer implements `Service` for now.
`hyper::server::conn::Serve` now returns `Connecting` instead of
`Connection`s, since `new_service` can now return a `Future`. The
`Connecting` is a future wrapping the new service future, returning
a `Connection` afterwards. In many cases, `Future::flatten` can be
used.
The `hyper::Server` is now a proper higher-level API for running HTTP
servers. There is a related `hyper::server::Builder` type, to construct
a `Server`. All other types (`Http`, `Serve`, etc) were moved into the
"lower-level" `hyper::server::conn` module.
The `Server` is a `Future` representing a listening HTTP server. Options
needed to build one are set on the `Builder`.
As `Server` is just a `Future`, it no longer owns a thread-blocking
executor, and can thus be run next to other servers, clients, or
what-have-you.
Closes#1322Closes#1263
BREAKING CHANGE: The `Server` is no longer created from `Http::bind`,
nor is it `run`. It is a `Future` that must be polled by an
`Executor`.
The `hyper::server::Http` type has move to
`hyper::server::conn::Http`.
**The `Error` is now an opaque struct**, which allows for more variants to
be added freely, and the internal representation to change without being
breaking changes.
For inspecting an `Error`, there are several `is_*` methods to check for
certain classes of errors, such as `Error::is_parse()`. The `cause` can
also be inspected, like before. This likely seems like a downgrade, but
more inspection can be added as needed!
The `Error` now knows about more states, which gives much more context
around when a certain error occurs. This is also expressed in the
description and `fmt` messages.
**Most places where a user would provide an error to hyper can now pass
any error type** (`E: Into<Box<std::error::Error>>`). This error is passed
back in relevant places, and can be useful for logging. This should make
it much clearer about what error a user should provide to hyper: any it
feels is relevant!
Closes#1128Closes#1130Closes#1431Closes#1338
BREAKING CHANGE: `Error` is no longer an enum to pattern match over, or
to construct. Code will need to be updated accordingly.
For body streams or `Service`s, inference might be unable to determine
what error type you mean to return. Starting in Rust 1.26, you could
just label that as `!` if you never return an error.
This dedicated `Entity` trait replaces the previous `Stream<Item=impl
AsRef<[u8]>, Error=hyper::Error>`. This allows for several improvements
immediately, and prepares for HTTP2 support.
- The `Entity::is_end_stream` makes up for change away from
`Option<Body>`, which was previously used to know if the body should be
empty. Since `Request` and `Response` now require a body to be set,
this method can be used to tell hyper that the body is actually empty.
It also provides the possibility of slight optimizations when polling
for data, by allowing to check `is_end_stream` before polling again.
This can allow a consumer to know that a body stream has ended without
polling for `None` afterwards.
- The `Entity::content_length` method allows a body to automatically
declare a size, in case a user doesn't set a `Content-Length` or
`Transfer-Encoding` header.
- It's now possible to send and receive trailers, though this will be
for HTTP2 connections only.
By being a trait owned by hyper, new methods can be added later as new
features are wanted (with default implementations).
The `hyper::Body` type now implements `Entity` instead of `Stream`,
provides a better channel option, and is easier to use with custom
streams via `Body::wrap_stream`.
BREAKING CHANGE: All code that was assuming the body was a `Stream` must
be adjusted to use an `Entity` instead.
Using `hyper::Body` as a `Stream` can call `Body::into_stream`
to get a stream wrapper.
Passing a custom `impl Stream` will need to either implement
`Entity`, or as an easier option, switch to `Body::wrap_stream`.
`Body::pair` has been replaced with `Body::channel`, which returns a
`hyper::body::Sender` instead of a `futures::sync::mpsc::Sender`.
Closes#1438
BREAKING CHANGE: `Method`, `Request`, `Response`, `StatusCode`,
`Version`, and `Uri` have been replaced with types from the `http`
crate. The `hyper::header` module is gone for now.
Removed `Client::get`, since it needed to construct a `Request<B>`
with an empty body. Just use `Client::request` instead.
Removed `compat` cargo feature, and `compat` related API.
