Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <416C4BCF.50204@gmx.de>
Date: Tue, 12 Oct 2004 23:25:35 +0200
From: r.pluem@t-online.de (=?UTF-8?B?UsO8ZGlnZXIgUGzDvG0=?=)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [RFC] a lazy byterange filter
References: <20041012130811.GC13375@redhat.com>
 <20041012163900.00002300@fe-pc-092.int.cinetic.de>
 <20041012151702.GB15464@redhat.com>
In-Reply-To: <20041012151702.GB15464@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


Joe Orton wrote:
> On Tue, Oct 12, 2004 at 04:39:00PM +0200, André Malo wrote:
> 
>>* Joe Orton <jorton@redhat.com> wrote:
>>
>>
>>>1) it's not particularly useful to be able to retrieve byteranges of the
>>>output of some SSI, CGI or PHP script output, if the output may change
>>>for each request anyway.
>>
>>Not agreed. It is, especially for download scripts very useful (which e.g.
>>count the number of downloads or whatever).
> 
> 
> OK sure, but the point you have to argue is why it's useful to support
> this feature *in httpd*.  N million 1.3 users live without it.  I'm
> arguing that you can and should implement byteranging in your CGI script
> if you want that, since that is the place where it is efficient to do
> so.  If you serve DVD images with your counting-CGI do you really want
> to pass 2Gb through the filter chain then discard it, for those "last 5
> bytes" byterange requests?
> 

I agree with André on that. Your DVD example is an extreme example. Most
times much less data will be transfered. Other applications that require the
current behaviour are CGI scripts / Tomcat servlets and jsps that protect downloads
with a custom authorization. So I fear the change will break partial downloads in these
situations and I do not think in general that every kind of application should implement
its own byteranging instead of doing this at a central position like the webserver.
I think the application should implement it by itself if the operation it does is

a) costly
b) produces very much data (like your DVD example)

On the other hand I understand the current problem. As far as I can see it is ONLY neccessary
to save the whole content in memory if the request contains multiple byteranges. If the request only
contains one byterange I think it would be sufficient to simply drop the uneeded data and only
forward the requested one. So my idea would be to have the behaviour of your patch if we have
multiple byteranges and the old behaviour if we have one byterange. But in this case the
code needs to be adjusted in a way that it drops all unneeded content immediately to avoid
the memory problem. Thoughts?


Regards

Rüdiger