error reading a body from connection: unexpected end of file

[andreubotella]

use anyhow::Error;
use hyper::{body::HttpBody, Client};

#[tokio::main]
async fn main() -> Result<(), Error> {
    let https = hyper_rustls::HttpsConnectorBuilder::new()
        .with_native_roots()
        .https_or_http()
        .enable_http1()
        .build();
    let client = Client::builder().build::<_, hyper::Body>(https);
    let url = "https://wpt.live/resources/testharness.js".parse()?;
    let mut resp = client.get(url).await?;
    let mut read = 0usize;
    while let Some(chunk) = resp.body_mut().data().await {
        read += chunk?.len();
        println!("Reading {} bytes...", read);
    }
    println!("Finished! Read {} bytes in total.", read);
    Ok(())
}

[...]
Reading 172032 bytes...
Reading 180224 bytes...
Reading 182423 bytes...
Error: error reading a body from connection: unexpected end of file

Caused by:
    unexpected end of file

This error happens consistently. It seems to be related to the length of the response, because https://wpt.live/resources/testharnessreport.js (2268 bytes) triggers it, but https://wpt.live/resources/ (1975 bytes) doesn't. It also seems to be related to the specific TLS configuration of the server, since I can't replicate by proxying from Deno Deploy.

This error doesn't happen on hyper-rustls 0.22.0, so it might be related to rustls 0.20.

[djc]

It might be useful to further minimize the reproduction case by getting hyper-rustls out of the loop; I expect this is caused by rustls/rustls#790 which is more or less intentional. If you want to further debug this (for example, using Wireshark and rustls configured with a KeyLogFile to enable SSLKEYLOGFILE) you could figure out if there's a difference between /resources/testharnessreport.js and /resources/ in whether they send a CloseNotify alert before closing their response stream.

[djc]

Upon further reflection, if the above issue is indeed at fault I think the best fix might be inside hyper, where we could ignore UnexpectedEof errors only for requests/responses that are deemed complete.

[cpu]

if the above issue is indeed at fault I think the best fix might be inside hyper, where we could ignore UnexpectedEof errors only for requests/responses that are deemed complete.

I think we can consider this resolved w/ hyperium/h2#743

[djc]

(It's a little unclear if this might still be an issue for HTTP 1.)

[cpu]

this might still be an issue for HTTP 1

Ah, should we leave it open then?

[djc]

Not sure -- probably okay to keep it closed, but let's keep in mind the nuance of the H2-only fix.