> I guess this is a shortcoming of streaming and eventsource protocols, > because there are two separate connections involved for each client, > whereas for websocket and long-polling haproxy can tell for sure the > connection breaks given there is only one connection.
I'm not familiar with those protocols, I would have guessed that the same issue affects all those (long-) polling connections, where the server delays its response until a specific event is triggered. > I guess option abortonclose is also good to have in general, since > it helps defend against DDoS attacks? Thats depends on your backend application; if your server has long- response times (whether aritifical like in the polling/streaming case or due to a slow application) then yes; for small static files it doesn't make sense I guess. > I do not see much side-effect for turning it on Its theoretically possibile that a client closes the session while waiting for the response, which is why this behavior is not fully HTTP compliant and thus disabled by default. I don't believe this is a practical problem though, since browsers don't behave this way. Regards, Lukas
