httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Tue, 13 Jul 2004 13:06:03 GMT
On Tue, 13 Jul 2004, Joe Orton wrote:

> On Mon, Jul 12, 2004 at 03:35:12AM +0100, Nick Kew wrote:
> > This doesn't completely address the issue that this might cause
> > excessive memory usage; particularly if we have to serve ranges in a
> > perverse order. I would propose two admin-configurable limits:
> >
> > (1) Total data buffered in memory by the byterange filter.  This can be
> > computed in advance from the request headers.  If this is exceeded, the
> > filter should create a file bucket to store the data, and the ordered
> > list then references offsets into the file.
> Buffering responses into temporary files so that the byterange filter
> can do its job sounds extremely messy.

Not as messy as buffering it in memory regardless of size.  But I agree
it's got to be configurable, and probably not a default.

> Being able to send byteranges of arbitrary dynamically generated content
> doesn't seem like an essential feature; the filter is just saying "I
> can't efficiently process a byterange request for this content".
> Clients must handle the 200 response fallback already.


The question is: can we offer admins alternatives, that might be
better in some situations, without messing memory.  I've put forward
suggestions, amplifying Ian's, on how I believe we can.

Nick Kew

View raw message