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. joe
