Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.2.1.2.2.20050804010923.03ce64f0@pop3.rowe-clan.net>
Date: Thu, 04 Aug 2005 01:13:08 -0500
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: SSL downloads faster than non SSL?
Cc: dev@httpd.apache.org
In-Reply-To: <42F176ED.5040704@apache.org>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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 :)