Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9F9658623 for ; Wed, 24 Aug 2011 21:16:48 +0000 (UTC) Received: (qmail 23212 invoked by uid 500); 24 Aug 2011 21:16:47 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 23133 invoked by uid 500); 24 Aug 2011 21:16:47 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 23125 invoked by uid 99); 24 Aug 2011 21:16:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2011 21:16:47 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [188.40.99.202] (HELO eru.sfritsch.de) (188.40.99.202) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2011 21:16:40 +0000 Received: from [10.1.1.6] (helo=k.localnet) by eru.sfritsch.de with esmtp (Exim 4.72) (envelope-from ) id 1QwKo6-0006cc-RD for dev@httpd.apache.org; Wed, 24 Aug 2011 23:16:19 +0200 From: Stefan Fritsch To: dev@httpd.apache.org Subject: Re: Fixing Ranges Date: Wed, 24 Aug 2011 23:16:17 +0200 User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; ) References: <20110824220643.17819937@baldur> In-Reply-To: <20110824220643.17819937@baldur> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108242316.18134.sf@sfritsch.de> 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?