On 8/24/2011 4:06 PM, Jim Jagielski 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. 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)… > > Sound OK?
Yup, sounds good. The only question is non-adjacent overlaps. Given Roy's pedantic example, I believe we should also start to dismiss any gap of less than X (80 bytes?) and provide those bytes as well in the merged range. Yes, clients may break. They were morons anyways for asking us to skip a few bytes for them and increase network traffic. Once the author accommodates the fact that they aren't in control, the response is semantically accurate. For that matter, perhaps User-Agent could be used to determine if we have a backwards-broken client for which we fall into the very well documented 200 response.
