Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 31626 invoked by uid 500); 7 May 2001 21:21:38 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 31464 invoked from network); 7 May 2001 21:21:34 -0000 Sender: harrie@lisanza.net Message-ID: <3AF692D6.C0FC64EA@covalent.net> Date: Mon, 07 May 2001 14:19:34 +0200 From: Harrie Hazewinkel Organization: Covalent Technologies X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org CC: httpd-2.0-cvs@apache.org Subject: Re: cvs commit: httpd-2.0/server/mpm/perchild perchild.c References: <3AF6FA0C.CB153050@algroup.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Ben Laurie wrote: [snip] > > Umm. I don't see how this will work with SSL - the number of bytes read > at the network layer does not correspond to anything happening at the > request layer... > > Seems to me that this is being used to do something rather magical and > protocol dependent... Would it not be an idea to spli the readbytes. 1 at the connection level and 1 at the application level. This of course makes the application level indeed application protocol specific. The connectin level just counts all bytes and the application level just counts that of the actual request. IMO, this would also be usefull for management purposes. -- phone: +39-3474932300 http://www.lisanza.net/