On 8/24/2011 3:45 PM, Dirk-WIllem van Gulik wrote: > > On 24 Aug 2011, at 21:39, Greg Ames wrote: > >> On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski <j...@jagunet.com >> <mailto: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.
At least, after 256 ranges or so, fall back to a 200 response in lieu of a 400/416 response.
