On Aug 24, 2011, at 3:10 PM, Greg Ames wrote: > > > On Wed, Aug 24, 2011 at 12:42 PM, Jim Jagielski <j...@jagunet.com> wrote: > > >From the above, I would be more comfortable with > > 0-, 40-50 ---> 0- > 0-499, 400-599 ---> 0-599 > 1000-1075, 1025-1088, 200-250, 1051-1100 --> 1000-1088, 200-250, 1051-1100 > > that it, merge as we can, but never resort... > > how about: > > 1000-2000,100-200,3000-4000,200-300,1999-3001 > > ? > > If we don't return a 416 for that due to overlap, I think the merge should be; > > 1000-4000,100-300
That's what Bill thinks as well, but that almost seems like a "resorting" to be, such that the 100-200 range (2nd requested) comes *after* the server sends 3000-4000, which is actually the 3rd range requested. > > 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 ;)
