On Tue, 13 Jul 2004, Joe Orton wrote:
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.
I'd tend to agree with this. But as long as the byte-ranges are in-order and not-overlapping, the byterange filter should still be able to handle the request without buffering anything. I couldn't tell you what percentage of byterange requests are like this (I've heard that Acrobat uses out-of-order ranges), but it should handle many simple cases.
Joshua.
