Stream do not close the file descriptor about tiny_httpd HOT 6 CLOSED

The command wrk -t 5 -c100 -d15 url on a small file gives a lot of 500 codes probably because of this.

from tiny_httpd.

I think it's good to close the connection if an option is set (--no-connection-reuse or whatever). Otherwise, a client might send another query. We might be able to set a timeout on how long it takes to send the new query, I'm not sure.

We have problems with slow lorris and other things, I'm afraid. In general it's going to be hard to be iron solid. A reverse proxy should be the way to do that cleanly if you're exposed to the public internet, and it can also handle TLS.

from tiny_httpd.

I don't understand ? What is slow lorris ? It does not seem costly to close the stream ? I don't speak about the connection socket, but the stream of the file being send over the socket. I just submitted PR #55, which is rather trivial.

from tiny_httpd.

Without this PR #55, a long running connection downloading many files will fail with EMFILE (no more file descriptor).
It is quite strange that this bug was not detected actually.

from tiny_httpd.

https://en.wikipedia.org/wiki/Slowloris_(computer_security)

but here you're talking about the stream in a response, which is not closed after being written back to the client, is that it? I guess it can be a leak indeed. I'm not sure why it did not pop up before; maybe we only did load testing with a server that didn't use streams with underlying FDs.

from tiny_httpd.

I think this is fixed by #55

from tiny_httpd.