On 24 Aug 2011, at 21:39, Greg Ames wrote: > On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski <j...@jagunet.com> wrote: > > > > > If we only merge adjacent ascending ranges, then it seems like an attacker > > could just craft a header where the ranges jump around and dodge our fix. > > > > I think no matter what, we should still have some sort of > upper limit on the number of range-sets we accept… after all, > merge doesn't prevent jumping around ;) > > > The problem I have with the upper limit on the number of range sets is the > use case someone posted for JPEG2000 streaming. That has a lot of range sets > but is completely legit. However, the ranges are in ascending order and > don't overlap. Maybe we could count overlaps and/or non-ascending order > ranges and fall back to 200 + the whole object if it exceeds a limit.
Right - and the other two use cases in the wild are - PDF readers - which fetch something at the start in RQ 1 and then the index form the end - and then quick looks images for each page and title pages. I've seen them do a second and 3rd request with many 10's of ranges. - Some of the streaming video (semi/pro) video editors - which fetch a bunch of i-Frames and do clever skip over stuff. Not in the high tens; but 10-15 ranges common. - Likewise for very clever MXF professional editing equipment - the largest case (yup - it did crash my server) tried to fetch over 2000 ranges :) So I think we really should endeavor to allow 50 to a few 100 of them. Or at the very least - make it a config option to cut off below 50 or so. Dw.
