httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: svn commit: r1161661 - /httpd/httpd/trunk/modules/http/byterange_filter.c
Date Fri, 26 Aug 2011 12:31:53 GMT

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:
>> 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.
View raw message