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
