> -----Original Message----- > From: Stefan Fritsch > Sent: Mittwoch, 24. August 2011 00:28 > To: dev@httpd.apache.org > Subject: Re: DoS with mod_deflate & range requests > > On Tuesday 23 August 2011, William A. Rowe Jr. wrote: > > On 8/23/2011 4:00 PM, Greg Ames wrote: > > > On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wrote: > > > I suggest we should be parsing and reassembling the list > > > before we start the bucket logic. > > > > > > I propose we satisfy range requests in the only sensible > > > manner, returning the ranges in sequence, > > > > > > yeah, overlapping ranges should be merged up front. That ought to > > > completely fix the issue. > > > > So the only remaining question; are we free to reorder them into > > sequence? > > Good point. I haven't seen anything in the RFC about that. I guess > that there are at least some clients that will be broken by that. > > Nevertheless, I have done a first try at a patch. The necessary > modification to only merge and not reorder should be small. I have > done only limited testing, so there are probably some bugs. There are > no tests with multiple ranges in the test-framework, yet. > > > Even in the most pedantic case, I believe that the total array > > shouldn't ever exceed 1024, because in those cases a large number > > of the acceptable expected ranges should be in the nnn-nnn, > > format, or 8 characters long, out of our MAX_LINE_LENGTH of some > > 8190. If we argue that asking for single bytes is simply wrong, > > we should probably allocate some 16 ranges and grow the list by a > > power of four, resulting in a max of some 4 allocs and maximum > > memory consumption of less than 64k per request. > > Just counting the commas in the header line seems acceptable > to me. In > any case, single byte ranges are explicitly mentioned in the RFC as > example, so we probably should not disallow those.
Patch looks good, but some comments: As far as I can see the following range request would not get merged: Range: bytes=0-0,1-1,2-2 into a 0-2 range as need_sort would remain 0. OTOH Range: bytes=0-0,0-1,1-2 would get get merged into a 0-2 range. Using boundary and !boundary in the later if statements to decide whether a request is multi range or single range is IMHO bad as boundary is set based on the old number ranges and not based on the number of merged ranges. So multiple ranges in the beginning might get merged to a single range in the end. Regards Rüdiger
