Move the extended parameter parser from the Content-Disposition header
implementation into the common header parsing module. This allows crates that
use Hyper to parse RFC 5987-compliant header parameter values.
Add tests based on the examples given in the RFC.
Methods added to `Client` and `Server` to control read and write
timeouts of the underlying socket.
Keep-Alive is re-enabled by default on the server, with a default
timeout of 5 seconds.
BREAKING CHANGE: This adds 2 required methods to the `NetworkStream`
trait, `set_read_timeout` and `set_write_timeout`. Any local
implementations will need to add them.
There is only one acceptable value for this header, "true", so
there header struct is unit-like (no fields nor data inside). See
documentation and tests for more info. Case insensitive.
Closes#655
Improve the compile-time of downstream crates that use RequestBuilder,
by not forcing them to remonomorphise and recompile its non-generic
methods when they use it: with this change, they can just call the
precompiled versions in the `hyper` object file(s). The `send` method is
the major culprit here, since it is quite large and complicated.
For an extreme example,
extern crate hyper;
fn main() {
hyper::Client::new().get("x").send().unwrap();
}
takes ~4s to compile before this patch (i.e. generic RequestBuilder) and
~2s after. (The time spent interacting with LLVM goes from 2.2s to
0.3s.)
BREAKING CHANGE: `RequestBuilder<U>` should be replaced by `RequestBuilder`.
compare the raw representations of the headers for the lack of a better alternative
helpful when asserting HttpRequest/ HttpResponse in tests elsewhere
Previously, hyper was defaulting to Chunked which adds a Transfer-Encoding
header, whenever there was no Content-Length header. RFC 7230 section 3.3.1
reads:
...
A server MUST NOT send a Transfer-Encoding header field in any
response with a status code of 1xx (Informational) or 204 (No
Content). A server MUST NOT send a Transfer-Encoding header field in
any 2xx (Successful) response to a CONNECT request
...
This commit fixes the cases of 1xx (Informational), 204 (No Content) by
using the EmptyWriter. It also uses EmptyWriter for 304 (NotModified) which
should not have a body.
It does NOT address the case of responses to CONNECT requests, or to HEAD
requests which do not send a body. These cases cannot be determined using
the data available in the response, and are left for future work.
When the Content-Length header is invalid, the Http11Message ends up
dropping the stream before returning the error. This causes a panic when
the `close_connection` method of the message is used later. This commit
fixes this by saving the stream onto the message instance before
returning the error. A regression test is also included.
When an Http11Message knows that the previous response should not
have included a body per RFC7230, and fails to parse the following
response, the bytes are shuffled along, checking for the start of the
next response.
Closes#640
- reading 0 bytes when SizedReader.remaining is more than 0 returns
"early eof" error
- reading 0 bytes when ChunkedReader.remaining is more than 0 returns
"early eof" error
- if SizedReader.remaining is less than buf.len(), the buf is sliced to
the remaining size
BREAKING CHANGE: This changes the signature of HttpWriter.end(),
returning a `EndError` that is similar to std::io::IntoInnerError,
allowing HttpMessage to retrieve the broken connections and not panic.
The breaking change isn't exposed in any usage of the `Client` API,
but for anyone using `HttpWriter` directly, since this was technically
a public method, that change is breaking.
