Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42F1E694.2050506@webthing.com>
Date: Thu, 04 Aug 2005 10:57:40 +0100
From: Nick Kew <nick@webthing.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050407)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: SSL downloads faster than non SSL?
References: <42EFDCB9.5010309@cfl.rr.com>
 <92e3673aaf98a7561602cad399ecc5c8@ricilake.net> <42EFEB8E.9000506@cfl.rr.com>
 <6.2.1.2.2.20050803080502.0611d6a0@pop3.rowe-clan.net>
 <42F0E742.2060208@cfl.rr.com>
 <6.2.1.2.2.20050803115813.06689220@pop3.rowe-clan.net>
 <42F176ED.5040704@apache.org>
 <6.2.1.2.2.20050804010923.03ce64f0@pop3.rowe-clan.net>
In-Reply-To: <6.2.1.2.2.20050804010923.03ce64f0@pop3.rowe-clan.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> At 09:01 PM 8/3/2005, Bill Stoddard wrote:
> 
>>A monitor thread would periodically check for a transmitfile 
>>completion status; if the completion status is too slow in 
>>coming, the monitor thread cancels the io and closes the socket.
> 
> 
> We really need not wait ;-)  Driving home from your neck of the
> woods in NC (well, a bit west in fact, near Fontana) it struck me
> that for all the individuals wishing for 'absolute' timeouts on
> unix platforms, it would be rather cool to cache the start time
> and run a parent thread against the scoreboard, killing all the
> lingering processes subject to byte-at-a-time DoS attacks in the
> headers.  We would obviously need to be careful of lengthy req
> bodies which would take more time than the 'absolute' timeout, but
> your comment reminded me that perhaps, we can kill two birds with
> one stone :) 

We can kill processes/threads that have spent too long in any given
scoreboard state: that's exactly what I needed to do when I proposed
what is now ap_hook_monitor.

But as for byte-at-a-time DOS attacks, I don't think (OTTOMH) it's
a good solution.  If we have a shortish timeout but up it for long
request bodies, the DOS simply mutates to sending
Content-Length: $BIG_RANDOM ... [byte] .... [byte] ....

-- 
Nick Kew