On Wednesday 24 August 2011, Dirk-WIllem van Gulik wrote: > > 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.
Do you know if those clients send the ranges in order? If they are sorted, it is easy to check if they are non-overlapping. And in that case, we could easily allow 1000 ranges.
