#900 http_upload does not close socket if client does not close it
What steps will reproduce the problem?
1. Watch for number of opened TCP sockets: ss -t | grep 5281 | wc -l
2. Upload any file via http_upload using Conversations (important!)
3. Watch for number of opened TCP sockets again
What is the expected output? What do you see instead?
Expected result: socket get closed after uploading file or after some short time.
Actual result: socket is in ESTABLISHED state and not closed.
What version of the product are you using? On what operating system?
Prosody 0.10 on Linux
Conversations 1.18.0 on Android
Please provide any additional information below.
Seems like Conversations does not close upload socket properly. Prosody doesn't close it either, so it would be in ESTABLISHED state for 5 days by default on Linux (net.netfilter.nf_conntrack_tcp_timeout_established).
Other web servers like Apache and nginx implement custom client request timeout. Prosody's Lua web server and/or http_upload should implement this timeout.
HTTP connections can be reused for multiple requests, so just closing them is not the right thing to do. Currently, if they stay silent, they should time out in about 6 hours. See #971
@ValdikSS Can you confirm whether the connections stay open for longer than Prosody's read timeout period?
Or whether Prosody is violating the HTTP protocol? (a HTTP packet capture would help us, but I appreciate that is harder with HTTPS involved). Some combinations of HTTP version+headers mean the server should close the connection, some combinations mean the server should leave it open until the client closes.
The connection closes after 6 hours. But that's too long in my opinion. Keep-alive connections should be closed in 15 minutes or so.
I would argue that this is a duplicate of #971 then.