On Wed, Aug 24, 2011 at 9:01 AM, "Plüm, Rüdiger,
Have you tried if the same happens with
mod_deflate, but with one of the
> Hmm - when I remove mod_deflate (i.e. explicitly as
it is the
> default in all our installs) and test on a / entry which
> static file which is large (100k)* - then I cannot get
> on its knees on a freebsd machine - saturating the
> connection it has (Note: the attack machines *are*
> saturated). The moment i put in mod_deflate,
> filter, etc - it is much easier to get deplete
> resources to notice.
as I cannot reproduce the issue with very small index.html
the proposed mitigations in place?
said my guess is that this might be an issue with mod_deflate that
unrelated to the Range request issue.
I think mod_deflate is just the tool to convert an O(N^2) data size
problem into an O(N^2) CPU usage problem, where N is some function of
LimitRequestLine. If the file size is smaller than the largest range end
used in the attack, it may reduce the amount of data actually going down the
don't think so. The compression happens before the byterange filter and the
byterange filter just hacks the already compressed brigade into more
buckets and rearranges them.
mod_deflate does not do more work if it is a range request. It
does the same amount of work as for the non range request.