rustls
error reading a body from connection: unexpected end of file
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.
It might be useful to further minimize the reproduction case by getting hyper-rustls out of the loop; I expect this is caused by https://github.com/rustls/rustls/pull/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.
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.
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/ https://github.com/hyperium/h2/pull/743
Not sure -- probably okay to keep it closed, but let's keep in mind the nuance of the H2-only fix.