On Aug 26, 2011, at 7:54 AM, Plüm, Rüdiger, VF-Group wrote: > > >> -----Original Message----- >> From: Jim Jagielski >> Sent: Freitag, 26. August 2011 13:38 >> To: [email protected] >> Subject: Re: svn commit: r1161661 - >> /httpd/httpd/trunk/modules/http/byterange_filter.c >> >> I still think that your version is wrong wrong wrong and am >> tempted to veto it. >> >> It completely invalidates what ap_set_byterange() is designed to >> do (set r->range) as well as removes the ability to count >> overlaps, non-ascends, etc... > > The question is: Does r->range need to reflect the range definition > that is actually delivered by the byte range filter? > The comment in httpd.h only says: > > /** The Range: header */ > > So you could put it vice versa and say r->range is not allowed to contain > an adjusted / optimized version of the Range header, but must contain > the original Range header. > To be honest I would not follow that, because the original Range header is > still > in r->headers_out and it makes sense to store an optimized version of the > Range header in r->range. >
My thoughts as well… > Nevertheless it is my opinion that it doesn't make sense to parse the Range > header twice. Agreed… The issue is that to merge, you need to parse… We could have ap_set_byterange() also return a set of start/stop points (in an array), so that the filter can work with that and not bother with rereading r->range. In fact, I think that makes the most sense… That is, adjust ap_set_byterange() to create the modified, parsed r->range, a return status and the start/stop array. The filter then goes thru that array.
