httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: DoS with mod_deflate & range requests
Date Thu, 25 Aug 2011 00:59:56 GMT

On Aug 24, 2011, at 4:56 PM, Roy T. Fielding wrote:

> On Aug 24, 2011, at 8:35 AM, Tim Bannister wrote:
>> On Tue, Aug 23, 2011, Roy T. Fielding wrote:
>>> And the spec says ...
>>>  When a client requests multiple ranges in one request, the
>>>  server SHOULD return them in the order that they appeared in the
>>>  request.
>>> My suggestion is to reject any request with overlapping ranges or more than five
ranges with a 416, and to send 200 for any request with 4-5 ranges.  There is simply no need
to support random access in HTTP.
>> Deshpande & Zeng in describe a method
for "streaming" JPEG 2000 documents over HTTP, using many more than 5 ranges in a single request.
>> A client that knows about any server-side limit could make multiple requests each
with a small number of ranges, but discovering that limit will add latency and take more code.
> I have no interest in supporting such a use case over HTTP.
> Consider how stupid it is to request ranges like their example
> Range: bytes=120-168,175-200,205-300,345-346,400-500,555-666,
>       667-800,900-1000,2500-2567,2890-3056,5678-9000,
>       10000-12004,12050-12060,15600-15605,17000-17001,
>       17005-17010,17050-17060,17800-17905,20000-20005
> keeping in mind that between each one of those ranges will be
> a multipart boundary of approximately 80 bytes!  Hence, any
> range request that contains gaps of less than 80 bytes should
> be considered a denial of service, or at least an idiot programmer
> that deserves to be slapped by Apache.
> To be clear, I am more than willing to rewrite the part on
> Ranges such that the above is explicitly forbidden in HTTP.
> I am not sure what the WG would agree to, but I am quite certain
> that part of the reason we have an Apache server is to protect
> the Internet from idiotic ideas like the above.

OK then… we seem to be coalescing into some consensus here…
basically, if the client sends stuff which is brain-dead stupid,
we simply 2000 and send the whole kit-and-kaboodle.

I'd like to propose that we update the byterange filter to perform
the following:

  o coalesce all adjacent ranges, whether overlapping or not.
    (eg: 200-250,251-300 & 200-250,220-300 both merge to 200-300)
  o We count:
     > the number of times a gap between ranges is <80bytes
     > the number of times we hit a descendent range
       (eg: 200-1000,2000-3000,1200-1500,4000-5000 would count as 1)
     > the number of ranges total (post ascending merge)
    If any >= some config-time limit, we send a 200

This is a start and was chosen simply for ease of implementation…
We can then expand it to be more functional…


View raw message