IMO, the function of ap_set_byterange() is to create the official working copy of r->range that will be used, and in doing so, provide first level verification of what is valid (as well as determining if we want to accept the byte-range as provided by the client or simply bail out with a 416 or 200).
If we are going to fix it, imo, we should do it here, but I'm +-0 on whether to ignore or break when we hit a wrong order… On Aug 26, 2011, at 3:03 AM, Ruediger Pluem wrote: > > > On 08/25/2011 08:33 PM, [email protected] wrote: >> Author: jim >> Date: Thu Aug 25 18:33:26 2011 >> New Revision: 1161681 >> >> URL: http://svn.apache.org/viewvc?rev=1161681&view=rev >> Log: >> Optimize... and break if we get eg 200-100 >> >> Modified: >> httpd/httpd/trunk/modules/http/byterange_filter.c >> >> Modified: httpd/httpd/trunk/modules/http/byterange_filter.c >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/byterange_filter.c?rev=1161681&r1=1161680&r2=1161681&view=diff >> ============================================================================== >> --- httpd/httpd/trunk/modules/http/byterange_filter.c (original) >> +++ httpd/httpd/trunk/modules/http/byterange_filter.c Thu Aug 25 18:33:26 >> 2011 >> @@ -566,6 +566,9 @@ static int ap_set_byterange(request_rec >> break; >> } >> end = number; >> + if (start > end) { >> + break; >> + } > > Previously we just ignored wrong ordered ranges and continued with the > remaining ones. > Wouldn't that mean that now we only process ranges up to a wrong ordered one? > >> if (!in_merge) { >> ostart = start; >> oend = end; >> @@ -575,7 +578,7 @@ static int ap_set_byterange(request_rec >> ostart = start; >> in_merge = 1; >> } >> - if (start > ostart && start < oend) { >> + if (start < oend) { >> in_merge = 1; >> } >> if ((end-1) >= oend) { >> >> >> >> > > Regards > > Rüdiger >
