Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3E556713.7010403@apache.org>
Date: Thu, 20 Feb 2003 15:38:59 -0800
From: Ian Holsman <ianh@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3b) Gecko/20030211
MIME-Version: 1.0
To: trawick@attglobal.net, dev@apr.apache.org
Subject: Re: [PATCH] clean up debug patch used with Apache 2 on daedalus
References: <3E55193F.3000507@attglobal.net>
In-Reply-To: <3E55193F.3000507@attglobal.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

+1 from me.
now all we need is a directive in httpd to turn this feature on I guess.

Jeff Trawick wrote:
> Network apps can all too often be tricked by clients into segfaulting or 
> worse.  When this occurs the first time, it can be important to know 
> what data was received and with what boundaries (i.e., how much was 
> passed up at a time to the app).
> 
> For quite a while (>1.5 years I think) www.apache.org has run with a 
> patch to APR which saves a certain amount of data read from the client. 
>  It is then used for debugging in the case of a segfault.  Having access 
> to the actual data and in what segments it was returned to Apache helped 
> fix some bugs pretty quickly.
> 
> I've cleaned up that patch a bit in hopes of showing how the 
> functionality could be added to APR.  In this new patch, the saving of 
> data is turned on by the app via a socket option rather than always 
> enabled as in the www.apache.org patch.
> 
> Is anybody for/against putting something like this in APR?
> 
> It would be nice to enable the app to change the parameters (how many 
> buffers to save, how much of each buffer to save).  I guess those could 
> be separate options in the future, with the current constants "20" and 
> "1024" simply the defaults.
> 
> It would also be nice to allow the app to retrieve the list of saved 
> input buffers, though it is still useful even without that feature.