httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: 2.2 approach for byterange?
Date Sun, 28 Aug 2011 21:19:02 GMT
On Sun, Aug 28, 2011 at 4:22 PM, Stefan Fritsch <sf@sfritsch.de> wrote:
> On Sunday 28 August 2011, Ruediger Pluem wrote:
>> On 08/28/2011 11:12 AM, Stefan Fritsch wrote:
>> > On Saturday 27 August 2011, Eric Covener wrote:
>> >> lots of threads.  Trying to resynch here, not a vote.
>> >>
>> >> For 2.2:
>> >>
>> >> [  ] everything in 2.3 (brigade_copy, mergeing, validation, ???)
>> >
>> > We don't know how many clients are broken by merging.
>> >
>> >> [X ] just the cheap brigade copy + sum_len > clen failsafe
>> >
>> > I think this should be sufficient.
>>
>> I agree, but maybe we should pass the brigade down the chain after
>> each range or at least after a specific number of ranges to avoid
>> piling up too much buckets in the byte range filter.
>
> OK, I have added that to 2.3, too.
>
> At http://people.apache.org/~sf/byterange-no-merge.2.2.diff is an
> adjusted version that has all range merging removed (but apart from
> that, all recent changes from 2.3 are in). The code to parse ranges
> into an array is not really necessary, but it keeps the diff to 2.3
> small. Is that the way to go?

+1 in concept, haven't reviewed.

Test drove and looked good, but wondering if we should have a single
merging switch in the trunk version and only flip it when we backport
directly?  I only worry about divergence between the two and the
cost/risk of manually merging if there is continued churn.   It did
not look especially clean to make the merge respect a big on/off
switch though either.

I'd also like to dump the MaxRanges after it stews a bit, in a
separate proposal, as the conensus in an early thread was that some
bound beyond header length was desired.

> Test byterange3.t fails, because it assumes range merging. Any idea
> how to limit that test to >= 2.3.15? It is rather different from the
> other tests (no explicit plan).

I put a kludge in for this that at least keeps it from blowing up on
old releases/versions.

Mime
View raw message