[Bug 63666] Should take the OS buffers into account when timing lingering
https://bz.apache.org/bugzilla/show_bug.cgi?id=63666 --- Comment #2 from Sjoerd Simons --- Unsure how to get those statistics in a good way. I'm not fully aware of which DOS it's protecting against (I assume leaving orphaned connection open in FIN-WAIT-2?). However a DOS that can trigger this with staying in FIN-WAIT-1 with data queued by stalling the download seems equivalent to an attacker stalling the connection at any other time (e.g. half way through the download rather then at the end). Unsure if apache has protection against that, but if so the protection for this corner should probably be equivalent. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 63666] Should take the OS buffers into account when timing lingering
https://bz.apache.org/bugzilla/show_bug.cgi?id=63666 --- Comment #1 from Joe Orton --- Interesting problem. Is there a portable way to determine the length of the TCP send queue? Apparently the ioctl TIOCOUTQ might do it for (some?) Unix, tho we've got no experience with using that in APR/httpd. Even if we can determine that length, I'm not sure what the right logic would be here. The existence of a non-zero send queue is not sufficient to delay the lingering close, since that's indistinguishable from a DoS which this is supposed to protect against. Maybe a *decreasing* length send queue would be sufficient, but possibly we'd need some heuristic on how fast it should to decrease to keep the socket open. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
