These are chat archives for IndySockets/Indy

6th
Mar 2017
Jeroen Wiert Pluimers
@jpluimers
Mar 06 2017 09:42
What would be a good defense mechanism on a server against HTTP clients keeping the connection open indefinitely with sending very little traffic?
mezen
@mezen
Mar 06 2017 09:45
Do the clients are sending valid HTTP traffic?
Jeroen Wiert Pluimers
@jpluimers
Mar 06 2017 09:58
Not always. Basically it's part of my previous questions on throttling. Basically this is to harden a server against wrong traffic and high loads of traffic (not even DoS or DDoS though I'm interested in preventing that as well.).
Matthijs ter Woord
@mterwoord
Mar 06 2017 13:33
hmm, disable http keep alive? ie, revert back to http 1.0?
Jeroen Wiert Pluimers
@jpluimers
Mar 06 2017 16:23
Some clients do not support http 1.0 and require keep alive; but they do keep communicating and never keep alive for more than like 60 seconds.
Remy Lebeau
@rlebeau
Mar 06 2017 18:00
Even if a client only supports HTTP 1.1+, the server always has final say in keep-alive handling. You could just set TIdHTTPServer.KeepAlive=False, that will work just fine for HTTP 1.1 clients. On the other hand, TIdHTTP and TIdHTTPServer currently support the 'Connection: keep-alive' header to keep a connection open, but they do not yet implement the 'Keep-Alive: <timeout>' header to timeout and close an open connection between requests. In TIdHTTPServer, at least, when KeepAlive=True, you could try setting the AContext.Connection.IOHandler.ReadTimeout property in the OnConnect event and let Indy raise an exception and close the connection if the client does not send any traffic within the timeout period. That won't really address DoS attacks, though.
Jeroen Wiert Pluimers
@jpluimers
Mar 06 2017 20:05
I'll try the last suggestion.
We need KeepAlive=True because some of the HTTP clients expect that.
Remy Lebeau
@rlebeau
Mar 06 2017 20:08
@jpluimers That is highly doubtful. All compliant clients are expected to support the 'Connection: close' header. The HTTP spec makes it clear that just because 'Connection: keep-alive' is the default behavior for an HTTP 1.1 request does not guarantee that all servers will use 'Connection: keep-alive' on their responses. HTTP keep-alives are always negotiated, never assumed or guaranteed (client asks for a keep-alive, the server responds yay or nay). And besides, if the server closes its end of the connection after sending a response, clients have no choice but to close their ends as well. Any TCP socket implement has to deal with the possibility of closed/lost connections and reconnects. HTTP is stateless, there is no guarantee that a connection will stay alive from one request to the next, so any HTTP client has to be prepared to reconnect on each new request if necessary