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. If we have a shortish timeout but up it for long request bodies, the DOS simply mutates to sending Content-Length: $BIG_RANDOM ... [byte] .... [byte] .... -- Nick Kew
