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