Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: 76.96.59.211 is neither permitted
 nor denied by domain of jim@jagunet.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1244.3)
Subject: Re: Fixing Ranges
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: <4E568A37.50304@rowe-clan.net>
Date: Thu, 25 Aug 2011 13:55:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DACBBE8-C297-45EE-BA4B-4EFB9A734E4A@jaguNET.com>
References: <20110824220643.17819937@baldur>
 <201108242316.18134.sf@sfritsch.de>
 <CAHSOX_Bm+uJ6bZ4tATa_1kmHGZizA_5tcVMt=-WgY2ddi5WyXw@mail.gmail.com>
 <201108250138.49474.sf@sfritsch.de>
 <E563FB5AB3F02844AC749BA39E494AB4052FC0FE@VF-MBX11.internal.vodafone.com>
 <F952FD3D-2C48-4D6A-88DC-D9F1EC6E236A@jaguNET.com>
 <5F975753-6B14-4F38-A0DB-113733FCCCDC@jaguNET.com>
 <E563FB5AB3F02844AC749BA39E494AB4052FC1AF@VF-MBX11.internal.vodafone.com>
 <33194F92-77F1-433D-80E1-A101A0662590@jaguNET.com>
 <4E568A37.50304@rowe-clan.net>
To: dev@httpd.apache.org


On Aug 25, 2011, at 1:45 PM, William A. Rowe Jr. wrote:

> On 8/25/2011 11:24 AM, Jim Jagielski wrote:
>> I'm playing around w/ ap_set_byterange() for the merging and
>> detection part, but that should not hold up release with the
>> optimized code=85
>>=20
>> I can do a 2.2.10 release with the byte range stuff once we
>> agree on the back port and confirm it fixes the problem...
>=20
> I guess I'm a bit confused... so the net brigade/range patch should
> be something reasonable anybody can apply to 2.0 / 2.2.  Let's get
> that net patch published as a fresh advisory by the end of the day?
>=20
> There doesn't seem to be a really good reason to release half of
> the solution, if many of us agree that 'something more' should be
> done, but it will take not only our consensus, but the http-wg group
> server authors to find consensus on how servers will react to extra
> quirky range requests starting at least in August '11.
>=20
> I'd rather see 2.2.10 implement that entire solution, even if this
> takes us a week.  Allowing 1-100,900-999,1-100,900-999 remains a
> DoS, even if this is a trivial one, because the resources returned
> exceed the reasonable resources required in bandwidth, cpu, even if
> we never wasted memory.
>=20

Right now, all adjacent overlaps are merged, and it is
trivial to add counting the number of merges done (will
add soonish) as well as the number of "direction changes"
(100-200,20-30 for eg)=85

We can then place limits on them, expose/log them, etc...=