`client` example fails with nginx on rapberrypi 4B

I've found that `client` example fails with nginx on raspberrypi 4B.
It's OK on local nginx and httpd on raspberry pi.

I slightly modified `client` example to my environment.

```rust
use async_h1::client;
use async_std::net::TcpStream;
use http_types::{Error, Method, Request, Url};

#[async_std::main]
async fn main() -> Result<(), Error> {
// Address for my raspberry pi 4B
// On raspberry pi, server is runnning via `docker run -d -p 80:80 nginx`
let stream = TcpStream::connect("192.168.10.50:80").await?;
let peer_addr = stream.peer_addr()?;
println!("connecting to {}", peer_addr);

for i in 0usize..2 {
println!("making request {}/2", i + 1);
let url = Url::parse(&format!("http://{}/", peer_addr)).unwrap(); // Changed URL to /
let req = Request::new(Method::Get, url);
let res = client::connect(stream.clone(), req).await?;
println!("{:?}", res);
// dbg!(res.body_string().await); // Works fine if this line is uncommented
}
Ok(())
}
```

And when it runs.
```
❯ cargo run --example client
Finished dev [unoptimized + debuginfo] target(s) in 0.06s
Running `target/debug/examples/client`
connecting to 192.168.10.50:80
making request 1/2
Response { status: Ok, headers: Headers { headers: {HeaderName("server"): [HeaderValue { inner: "nginx/1.17.10" }], HeaderName("connection"): [HeaderValue { inner: "keep-alive" }], HeaderName("content-type"): [HeaderValue { inner: "text/html" }], HeaderName("accept-ranges"): [HeaderValue { inner: "bytes" }], HeaderName("last-modified"): [HeaderValue { inner: "Tue, 14 Apr 2020 14:19:26 GMT" }], HeaderName("etag"): [HeaderValue { inner: "\"5e95c66e-264\"" }], HeaderName("date"): [HeaderValue { inner: "Sat, 09 May 2020 08:36:04 GMT" }], HeaderName("content-length"): [HeaderValue { inner: "612" }]} }, version: None, sender: Some(Sender { .. }), receiver: Receiver { .. }, body: Body { reader: "", length: Some(612) }, local: TypeMap }
making request 2/2
Error: invalid HTTP version
```
Failed on second request.
> // dbg!(res.body_string().await); // Works fine if this line is uncommented

As I commented above, it succeeds if read the body of the first request.

After some investigation, I've found that `async-h1` reads the first body as the second header and fails.
Still, I don't know why it fails only nginx on raspberry pi and success on other servers.

Start with the `client` example entry point run by `cargo run --example client` and the `async_h1::client::connect` response handling. Reproduce the second-request failure against nginx on a Raspberry Pi, comparing it with the working local nginx and httpd cases. Done means two requests succeed without reading the first response body manually.

Written by the indexing model from the issue text.