Nick Kew wrote:
William A. Rowe, Jr. wrote:
At 09:01 PM 8/3/2005, Bill Stoddard wrote:
A monitor thread would periodically check for a transmitfile
completion status; if the completion status is too slow in
coming, the monitor thread cancels the io and closes the socket.
We really need not wait ;-) Driving home from your neck of the
woods in NC (well, a bit west in fact, near Fontana) it struck me
that for all the individuals wishing for 'absolute' timeouts on
unix platforms, it would be rather cool to cache the start time
and run a parent thread against the scoreboard, killing all the
lingering processes subject to byte-at-a-time DoS attacks in the
headers. We would obviously need to be careful of lengthy req
bodies which would take more time than the 'absolute' timeout, but
your comment reminded me that perhaps, we can kill two birds with
one stone :)
We can kill processes/threads that have spent too long in any given
scoreboard state: that's exactly what I needed to do when I proposed
what is now ap_hook_monitor.
But as for byte-at-a-time DOS attacks, I don't think (OTTOMH) it's
a good solution.
Of course your right, anything we do at the HTTP layer against DoS attacks is easy for a clever attacker to
circumvent. Need to go into deeper into the TCP stack to mount an effective defense against DoS attacks. OTOH,
blocking the simple stuff at the HTTP layer is often 'good enough' in practice.
