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
