Look Jim, as someone who has written a HTTP parsing library with a good track record of no published security holes, take my criticism of what you wrote for what it's worth. I have no idea what your plans are, was simply agreeing with Stefan's critique of your code.
>________________________________ >From: Jim Jagielski <[email protected]> >To: [email protected]; Joe Schaefer <[email protected]> >Sent: Thursday, August 25, 2011 5:29 PM >Subject: Re: svn commit: r1161661 - >/httpd/httpd/trunk/modules/http/byterange_filter.c > >And who said this was the final version? Not me... > >My plan was to simply add elements to an array and then >apr_array_pstrcat()... > >On Thu, Aug 25, 2011 at 02:14:05PM -0700, Joe Schaefer wrote: >> My criticism has to do with your implementation. >> There's no point in fixing exploitable code with >> a differently exploitable implementation. Just >> buffer things in an internal array and merge the >> string once at the end of the loop, and *not* as >> you iterate over the elements of the range header. >> >> -------------------------------------------------------------------------- >> >> From: Jim Jagielski <[email protected]> >> To: [email protected] >> Sent: Thursday, August 25, 2011 5:10 PM >> Subject: Re: svn commit: r1161661 - >> /httpd/httpd/trunk/modules/http/byterange_filter.c >> >> On Aug 25, 2011, at 5:02 PM, Joe Schaefer wrote: >> >> > +1, also has the advantage of not being a quadratic >> > allocator the way Jim's usage of apr_pstrcat is. >> > >> >> So what, exactly, will ap_set_byterange() do***? It was >> my impression that it created our r->range entry... > >-- >=========================================================================== > Jim Jagielski [|] [email protected] [|] http://www.jaguNET.com/ > "Great is the guilt of an unnecessary war" ~ John Adams > > >
