httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Slive <>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Tue, 13 Jul 2004 13:59:35 GMT

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.


View raw message