On Wed, Aug 24, 2011 at 10:33 AM, "Plüm, Rüdiger,
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 filter chain.
I 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
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.
OK, thanks for the clarification, Rüdiger. Then I don't understand
why mod_deflate seems to be an important factor in killing the
If the DEFLATE filter runs first, can you do anything
useful with a subrange of its output? i.e., could a client decompress a
subrange that starts in the middle of the compressed version and get a
subrange of the original uncompressed data?
depends. Think of a download that was broken in the middle and that was
compressed by mod_deflate on the fly. A client could just request the missing
bits and decompress the whole thing
guess in general it only works if the client has all the missing pieces (or at
least the ones before the contents of the partial response) that are not sent
via the partial response at hand to
decompress the whole stream (or decompress at least until the last
part of the partial response).