________________________________
From: Greg Ames [mailto:ames.g...@gmail.com]
Sent: Mittwoch, 24. August 2011 18:20
To: dev@httpd.apache.org
Subject: Re: Mitigation Range header
On Wed, Aug 24, 2011 at 10:33 AM, "Plüm, Rüdiger, VF-Group"
<ruediger.pl...@vodafone.com> 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.
Greg
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?
Greg
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
afterwards.
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).
Regards
Rüdiger
