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 <jim@jagunet.com
>> <mailto:jim@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.
|