From: Greg Ames []
Sent: Mittwoch, 24. August 2011 18:20
Subject: Re: Mitigation Range header

On Wed, Aug 24, 2011 at 10:33 AM, "Plüm, Rüdiger, VF-Group" <> wrote:

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 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.

OK, thanks for the clarification, Rüdiger.  Then I don't understand why mod_deflate seems to be an important factor in killing the server.
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?

It 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
I 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).