You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a post request with a large body gets error (413 or 404 or any other) as a response, the connection doesn't close, but hangs in CLOSE-WAIT state
Expected Behavior
After getting error connection is closed successfully
Current Behavior
Connection hangs in CLOSE-WAIT state with some bytes in Recv-Q
Possible Solution
As it only happens to requests with a large body, I guess there is something to do with the bytes that weren't read from a socket at the time the error happens. So we need to make sure these bytes are being read before closing the socket.
Steps to Reproduce (for bugs)
Creating simple server
use actix_web::{App,HttpServer};#[actix_web::main]pubasyncfnmain(){HttpServer::new(move || {App::new()}).bind("127.0.0.1:5556").unwrap().run().await.unwrap();}
Making request with large body, that will end up with an error (404 in this case)
We have an application that uses actix-web as http-api server. We've discovered that at some point it starts leaking the memory and connections. We've also found that another application is sending huge files to our app and keeps retrying as it gets 413 error. Future investigation showed that these things are connected and every 413 error leaves a connection in CLOSE-WAIT state. Later we managed to reproduce this problem with other errors (like 404 in the minimal example)
Your Environment
Rust Version: 1.70.0
Actix Web Version: 4.4.0
The text was updated successfully, but these errors were encountered:
If a post request with a large body gets error (413 or 404 or any other) as a response, the connection doesn't close, but hangs in
CLOSE-WAIT
stateExpected Behavior
After getting error connection is closed successfully
Current Behavior
Connection hangs in
CLOSE-WAIT
state with some bytes inRecv-Q
Possible Solution
As it only happens to requests with a large body, I guess there is something to do with the bytes that weren't read from a socket at the time the error happens. So we need to make sure these bytes are being read before closing the socket.
Steps to Reproduce (for bugs)
CLOSE-WAIT
state with a lot of bytes inRecv-Q
$ ss -n4t | grep 5556 FIN-WAIT-2 0 0 127.0.0.1:59240 127.0.0.1:5556 CLOSE-WAIT 787381 0 127.0.0.1:5556 127.0.0.1:59240
Context
We have an application that uses actix-web as http-api server. We've discovered that at some point it starts leaking the memory and connections. We've also found that another application is sending huge files to our app and keeps retrying as it gets 413 error. Future investigation showed that these things are connected and every 413 error leaves a connection in
CLOSE-WAIT
state. Later we managed to reproduce this problem with other errors (like 404 in the minimal example)Your Environment
The text was updated successfully, but these errors were encountered: