On Wednesday 24 August 2011, Nick Kew wrote: > AFAICS[1], we've discussed an advisory and some protections > users can deploy. For the future we should be looking at > a robust solution that prevents Range requests only when > they're likely to present a problem. > > Most obviously, we should be able to serve arbitrary ranges > from any static or cached file without sweat to support > apps such as JPEG2000 or PDF streaming. That can be done > much more efficiently at source than in a ranges filter. > > Does this look like a plan? > > 1. Add Ranges capability into the default handler and mod_cache. > They could then set a "ranges-handled" flag in r->notes. > 2. Insert the Ranges filter according to the logic that's > been discussed here today. > 3. The Ranges filter then checks ranges-handled, and removes > itself if set, to avoid returning recursive ranges. > > I guess implementing that would imply factoring out the > multipart encoding stuff from the range filter into an API.
This looks like an awful lot of work for me to fix something that should be a simple issue. And it is definitely too intrusive for 2.2. I have another idea: Instead of using apr_brigade_partition write a new function ap_brigade_copy_part that leaves the original brigade untouched. It would copy the necessary buckets to a new brigade and then split the first and last of those copied buckets as necessary and destroy the excess buckets. AFAICS, this would reduce the quadratic growth into linear. Do you think that would solve our problems?
