On Aug 24, 2011, at 2:43 PM, Tim Bannister wrote: > On 24 Aug 2011, at 17:47, Stefan Fritsch wrote: > On Wednesday 24 August 2011, Jim Jagielski wrote: >>> On Aug 24, 2011, at 12:05 PM, Plüm, Rüdiger, VF-Group wrote: >>>> >>>> But merging might require sorting... >>> >>> then we don't do that merge, imo… In other words, we progress thru the set >>> of ranges and once a range is merged as far as it can be (due to the next >>> range not being merge-able with the previous one), we let it go... >> >> We could also use a two stage approach: Up to some limit (e.g. 50) ranges, >> we return them as the client requested them. Over that limit, we violate the >> RFC-SHOULD and sort and merge them. > > Another option is just to return 200. Servers MAY ignore the Range header. I > prefer this because existing clients already handle that case well, and > there's no opportunity for a client to exploit this (“malicious” clients that > want the whole entity need only request it). > > Can anyone see why returning 200 for these complex requests (by ignoring > Range / If-Range) is a bad idea?
In what cases would we ignore it? Dependent only on >=X ranges? It does seem that 14.5 gives us this as an out...
