Error `connection closed before message completed` after 60s
joshua-tree-19231 opened this issue · 2 comments
Version
v0.3.6
Platform
Linux backend1 5.10.0-17-amd64 #1 SMP Debian 5.10.136-1 (2022-08-13) x86_64 GNU/Linux
Cloud provider: OVH
Description
Got error "connection closed before message completed" from hyper::server::server::new_svc
when I make a request that's long (>60s), coming from:
I tried this code:
pub fn do_my_thing() -> impl Filter<Extract = (impl warp::Reply,), Error = warp::Rejection> + Clone {
warp::path!("v0" / "do_my_thing")
.and(warp::post())
.and(warp::body::content_length_limit(1024 * 16))
.and(warp::body::json())
.and_then(do_my_thing_handler)
.with(warp::log(LOG_TARGET))
.recover(errors::handle_rejection)
}
// Then:
warp::serve(do_my_thing())
The thing is, the do_my_thing_handler
can take anywhere from 2s to 90s. And when in takes too long (>60s when counting in my head), I don't get any response, and instead get the above error "connection closed before message completed".
On the client using Postman, I get Error: socket hang up
. With curl, it's Empty reply from server
I expected to see this happen: [explanation]
Return the response in any case, when the handler takes 2s or 60s.
Instead, this happened: [explanation]
I get an error on my client:
- curl: 52 empty reply from server
- Postman: socket hang up
See logs (also see times).
2023-12-12T19:34:02.815976Z DEBUG hyper::proto::h1::io: parsed 10 headers
2023-12-12T19:34:02.816018Z DEBUG hyper::proto::h1::conn: incoming body is content-length (92 bytes)
2023-12-12T19:34:02.817115Z DEBUG hyper::proto::h1::conn: incoming body completed
-- snip start --
do my own thing, takes ~60s
-- snip end --
2023-12-12T19:35:02.802905Z DEBUG hyper::server::server::new_svc: connection error: connection closed before message completed
2023-12-12T19:35:03.236297Z DEBUG hyper::proto::h1::io: parsed 0 headers
2023-12-12T19:35:03.236329Z DEBUG hyper::proto::h1::conn: incoming body is empty
The response is correct when my own handler does its job in less than 60s.
Other notes
I also checked hyperium/hyper#2136, but it seems like the other issue is more on the client side, e.g. using reqwest.
I have the same problem using reqwest
Encountering the same issue when using both reqwest and surf.