httpd-dev mailing list archives

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

On Aug 26, 2011, at 10:34 AM, Plüm, Rüdiger, VF-Group wrote:

> 
> 
>> -----Original Message-----
>> From: Jim Jagielski [mailto:jim@apache.org] 
>> Sent: Freitag, 26. August 2011 16:27
>> To: dev@httpd.apache.org
>> Subject: Re: svn commit: r1161661 - 
>> /httpd/httpd/trunk/modules/http/byterange_filter.c
>> 
>>> 
>>> I guess we can do both: Count the ',' and give the number 
>> to apr_array_make
>>> 
>> 
>> Doesn't that mean that someone can craft a nasty Range (e.g: 
>> 0-0,1-1,2-2,
>> 3-3,....99999999-99999999 and cause us to preallocate a bunch
>> of memory when at the end we'll get 0-99999999 ???
> 
> In principal yes. Two things can happen:
> 
> 1. The ranges are valid and do not overlap or are not mergable. In this
>   case we need to allocate that memory anyway.
> 
> 2. The ranges are mergable. In this case we allocate too much memory
>   for the array. But this effect is limited by the maximum length a header field can
>   have. And if this is not enough do a sane cut for the preallocation:
> 
>   MIN(number of ranges, MAX_PREALLOCATED_ARRAY_MEMBERS)
> 
> This should work fine for the typical use case where we can't merge anything
> and avoid running in a DoS trap if we have a large number of mergable ranges.
> 

The current rev just allocates memory when needed….
Mime
View raw message