On Thu, Sep 8, 2011 at 2:45 PM, Jeff Trawick <[email protected]> wrote: > On Thu, Sep 8, 2011 at 2:17 PM, William A. Rowe Jr. <[email protected]> > wrote: >> On 9/8/2011 11:44 AM, Jeff Trawick wrote: >>> On Thu, Sep 8, 2011 at 11:16 AM, Jeff Trawick <[email protected]> wrote: >>>> Here's what I have at present: >>>> http://people.apache.org/~trawick/2.2.20-byterange-fixes.txt >>>> >>>> (compiled-in max ranges, uses same AP_ symbol as 2.2.21 even though >>>> the compiled-in version isn't the same type of "DEFAULT") >>>> >>> >>> See also http://people.apache.org/~trawick/2.2.19-byterange-fixes.txt for >>> 2.2.19 >> >> Lovely! I think this file is far more useful, since anyone who already >> adopted .20 should be in a good position to adopt .21, while someone >> sitting back on .15 (or .9, gasp) might have a much bigger headache. >> >>> I've tested this latter patch with current framework and a separate >>> test for numranges>200 with 2.2.14, 2.2.15, and 2.2.19. (2.2.14 needs >>> r916627, or at least the subset of it for byterange_filter.c, before >>> applying the patch.) >> >> On the 2.0 side, nothings changed since 2.0.55 that should break the patch. > > BTW, do any of us have an updated 2.0 patch to reflect the important > changes since last weekend? If not, I'll need to work on thatin the > short term. > >> On the 2.2 side, we might want to publish an apply_to_2.2.14 and 2.2.19, >> just given that 2.2.9+ (which the .14 applies to) has only now reached 3 >> years old. I see no real value in working out a <2.2.8 patch /shrug > > works for me > > I'll get a 2.2.14-no-caveats patch together (i.e., no prepatch of > r916627 required).
http://people.apache.org/~trawick/2.2.14-byterange-fixes.txt
