httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Tue, 13 Jul 2004 09:52:51 GMT
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.

I'm beginning to think the only sane way to fix the byterange filter is
to have it do nothing if it isn't passed a complete EOS-terminated
brigade with a predetermined length, i.e. no morphing CGI buckets which
will eat all your RAM when they get ->read().

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.


View raw message