Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Tue, 13 Jul 2004 11:44:46 +0100
From: Joe Orton <jorton@redhat.com>
To: Graham Leggett <minfrin@sharp.fm>
Cc: dev@httpd.apache.org
Subject: Re: The Byterange filter -- a new design -- feel free to rip it to
 shreds
Message-ID: <20040713104446.GE30998@redhat.com>
Mail-Followup-To: Graham Leggett <minfrin@sharp.fm>, dev@httpd.apache.org
References: <40F1F1C6.4030400@apache.org> <40F279BA.7050002@sharp.fm>
 <Pine.LNX.4.53.0407121400490.20952@hugin.webthing.com>
 <40F296D4.7090303@sharp.fm> <20040713100138.GA31617@redhat.com>
 <40F3B7DC.4060609@sharp.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <40F3B7DC.4060609@sharp.fm>
User-Agent: Mutt/1.4.1i

On Tue, Jul 13, 2004 at 12:22:20PM +0200, Graham Leggett wrote:
> Joe Orton wrote:
> 
> >As far as I can tell the byterange filter should handle all such cases
> >correctly already: read ap_set_byterange() - it punts on a non-200
> >r->status or when r->headers_out contains a Content-Range header etc. 
> >Is this side-discussion just theoretical pondering or is there some real
> >issue you're trying to solve?
> 
> When you say "it punts" what do you mean - that it removes itself from 
> the filter stack (as in "my work here is already done")? If this is the 
> case, then it works correctly already.

Yes, that's exactly what it's supposed to do already.  I haven't checked
that it works via the proxy but it certainly does for other cases.

> The problem arises when large data sizes (say a 650MB CD ISO) are stored 
> in a multi-tier webserver architecture (mod_proxy in front of a backend, 
> for example), and somebody comes along and tries to download it using a 
> download accelerator, or they simply try to resume a failed download.
> 
> The full 650MB CD ISO is then transferred from the backend to the 
> frontend, which then pulls out the bits the frontend needs dumping the 
> rest. And this happens once for every single byte range request.

And buffered into RAM each time too, nice.  This is another good case
for the byterange filter not doing any work for anything other than
"simple" content per my other mail.

joe