On Wed, Aug 24, 2011 at 5:06 PM, Jim Jagielski <j...@jagunet.com> wrote:
> I'm cool w/ that… treat non-ascending ranges as potential hinky > and count those and only allow a certain number of them… > > Still not sure if we should count overlaps as bad or not… > that RFC example troubles me: > > 14.35.1 Byte Ranges > - Several legal but not canonical specifications of the second 500 > bytes (byte offsets 500-999, inclusive): > bytes=500-600,601-999 > bytes=500-700,601-999 > > The 2nd seems to imply that one *MUST* merge adjacent overlaps to get the > correct response (500 bytes not 201+399=600bytes) > > With all that in mind, I am still of the opinion that any > adjacent overlaps should be merged… > So how about we parse Range and merge all adjacent overlaps > (or merges (200-249,250-999 would merge into 200-999); > We then count how many non-ascends are in that revised set of > ranges and 200 out if it exceeds some config limit. Sounds good to me. Maybe re-define an overlap to include gaps of less than 80 bytes, per Roy's comments, and merge those too. > We can also > provide some overall limit on the number of ranges, or at least > the ability to add one (a default of 0 means unlimited)… > sure, but it feels less urgent than the above. Greg
