Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of ames.greg@gmail.com
 designates 209.85.213.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <84E62DCF-D765-4A97-A5D3-71F9E7233FA9@jaguNET.com>
References: <alpine.DEB.2.00.1108231306230.24177@eru.sfritsch.de>
	<4E53EEEF.2060409@rowe-clan.net>
	<201108232049.58021.sf@sfritsch.de>
	<4E540062.4040903@rowe-clan.net>
	<CAHSOX_AGmaMJ=qkv7WCwaNXgpGB_+xcg9ZCA_cMi5Zo3+bWdCw@mail.gmail.com>
	<4E541CE5.1080608@rowe-clan.net>
	<DE3804B8-18F2-45B9-8A24-FE95C44CA3CA@gbiv.com>
	<20110824153559.GA24702@nebula.c8h10n4o2.org.uk>
	<71A86EB1-CCBA-40E9-A853-02C2CC3400A6@bbc.co.uk>
	<E563FB5AB3F02844AC749BA39E494AB4052FBF7D@VF-MBX11.internal.vodafone.com>
	<4E55253C.3050905@rowe-clan.net>
	<08F45893-EBFE-4C35-BE1E-37F2189D194D@jaguNET.com>
	<CAHSOX_D9dB8A5LUs4_6dh14_qkUT5W32wezzCFbGAxdKKNHrug@mail.gmail.com>
	<A91D84B6-65B4-48DE-A1D4-B4FAC1A24F83@jaguNET.com>
	<CAHSOX_B9DMUY+UMswrjkuOBQSzaiL8cC28boH3JC6dygq7yNUw@mail.gmail.com>
	<84E62DCF-D765-4A97-A5D3-71F9E7233FA9@jaguNET.com>
Date: Wed, 24 Aug 2011 17:32:48 -0400
Message-ID: 
 <CAHSOX_CVFfd+Oj_6Yg2Wv68pBkEgx87276G7H9evQBQkMR3ZCg@mail.gmail.com>
Subject: Re: DoS with mod_deflate & range requests
From: Greg Ames <ames.greg@gmail.com>
To: dev@httpd.apache.org
Content-Type: multipart/alternative; boundary=20cf303f6a5ac280da04ab470d00

--20cf303f6a5ac280da04ab470d00
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 24, 2011 at 5:06 PM, Jim Jagielski <jim@jagunet.com> wrote:

> I'm cool w/ that=85 treat non-ascending ranges as potential hinky
> and count those and only allow a certain number of them=85
>
> Still not sure if we should count overlaps as bad or not=85
> that RFC example troubles me:
>
> 14.35.1 Byte Ranges
>       - Several legal but not canonical specifications of the second 500
>        bytes (byte offsets 500-999, inclusive):
>         bytes=3D500-600,601-999
>         bytes=3D500-700,601-999
>
> The 2nd seems to imply that one *MUST* merge adjacent overlaps to get the
> correct response (500 bytes not 201+399=3D600bytes)
>
> With all that in mind, I am still of the opinion that any
> adjacent overlaps should be merged=85
>

So how about we parse Range and merge all adjacent overlaps
> (or merges (200-249,250-999 would merge into 200-999);
> We then count how many non-ascends are in that revised set of
> ranges and 200 out if it exceeds some config limit.


Sounds good to me.  Maybe re-define an overlap to include gaps of less than
80 bytes, per Roy's comments, and merge those too.


> We can also
> provide some overall limit on the number of ranges, or at least
> the ability to add one (a default of 0 means unlimited)=85
>

sure, but it feels less urgent than the above.

Greg

--20cf303f6a5ac280da04ab470d00
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Aug 24, 2011 at 5:06 PM, Jim Jag=
ielski <span dir=3D"ltr">&lt;<a href=3D"mailto:jim@jagunet.com">jim@jagunet=
.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I&#39;m cool w/ that=85 treat non-ascending ranges as potential hinky<br>
and count those and only allow a certain number of them=85<br>
<br>
Still not sure if we should count overlaps as bad or not=85<br>
that RFC example troubles me:<br>
<br>
14.35.1 Byte Ranges<br>
<div class=3D"im"> =A0 =A0 =A0- Several legal but not canonical specificati=
ons of the second 500<br>
 =A0 =A0 =A0 =A0bytes (byte offsets 500-999, inclusive):<br>
 =A0 =A0 =A0 =A0 bytes=3D500-600,601-999<br>
 =A0 =A0 =A0 =A0 bytes=3D500-700,601-999<br>
<br>
</div>The 2nd seems to imply that one *MUST* merge adjacent overlaps to get=
 the<br>
correct response (500 bytes not 201+399=3D600bytes)<br>
<br>
With all that in mind, I am still of the opinion that any<br>
adjacent overlaps should be merged=85<br>
=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt =
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
So how about we parse Range and merge all adjacent overlaps<br>
(or merges (200-249,250-999 would merge into 200-999);<br>
We then count how many non-ascends are in that revised set of<br>
ranges and 200 out if it exceeds some config limit. </blockquote><div><br>S=
ounds good to me.=A0 Maybe re-define an overlap to include gaps of less tha=
n 80 bytes, per Roy&#39;s comments, and merge those too.<br>=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-=
left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
We can also<br>
provide some overall limit on the number of ranges, or at least<br>
the ability to add one (a default of 0 means unlimited)=85 <br></blockquote=
><div><br>sure, but it feels less urgent than the above. <br><br>Greg</div>=
</div>

--20cf303f6a5ac280da04ab470d00--