httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Fixing Ranges
Date Fri, 26 Aug 2011 06:05:54 GMT
On 8/25/2011 1:27 PM, Dirk-Willem van Gulik wrote:
> 
> On 25 Aug 2011, at 17:45, Greg Ames wrote:
> 
>> On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski <jim@jagunet.com> wrote:
>> Now that the memory utilz is being fixed, we need to determine
>> what sort of usage we want to allow… I'm guessing that people
>> are ok with http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
>> as the guiding spec?
>>
>> I'm no longer convinced that we *need* to merge/optimize the Range header.  Stefan's
fix to the brigade plumbing has converted O(N^2) memory + CPU use into something scalable.
 
> 
> Same feeling here. BUT that is based on the FreeBSD platform I care about. And we have
noticed earlier that Ubuntu (which its default commit pattern in the vm) behaves very differently.

> 
> So is it fair to assume this reasoning holds across the board -- or should we get some
very explicit +1's on this appraoch from key linux, windows and what not users ?

I'm convinced we must do both, inhibit all redundant range requests,
and coalesce ranges as illustrated by the spec, particularly on the
assumption that any redundant ranges are likely malicious.  And due
to the memory consumption, rewinding should simply be eliminated.
The user agent is always free to pipeline multiple requests for
specific subranges.

At this point, should we publish the most conservative flavor of our
provisional patch *** with a pointer to a specific page on our wiki ***
so that we can collect feedback of any clients/applications which are
impacted by the most conservative patch?

That will help us not only skip coding bypass options for things which
apparently need to bypass, but guide users in applying those options.

The wiki page/patch could even offer suggestions on disabling certain
restrictions (e.g. ALLOW_BYTERANGE_REWIND) which can later be turned
into configuration flags.

I'd suggest getting something into compiler-literate administrators'
hands beats some rush to a fragile/unstable/incomplete 2.2.20.


Mime
View raw message