httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Plüm, Rüdiger, VF-Group" <>
Subject RE: Mitigation Range header
Date Wed, 24 Aug 2011 16:37:04 GMT


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


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

View raw message