Return-Path: owner-new-httpd Received: by taz.hyperreal.com (8.6.10/8.6.5) id MAA14573; Mon, 8 May 1995 12:26:15 -0700 Received: from life.ai.mit.edu by taz.hyperreal.com (8.6.10/8.6.5) with SMTP id MAA14566; Mon, 8 May 1995 12:26:12 -0700 Received: from volterra (volterra.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) for new-httpd@hyperreal.com id AA19767; Mon, 8 May 95 15:25:37 EDT From: rst@ai.mit.edu (Robert S. Thau) Received: by volterra (4.1/AI-4.10) id AA02946; Mon, 8 May 95 15:25:34 EDT Date: Mon, 8 May 95 15:25:34 EDT Message-Id: <9505081925.AA02946@volterra> To: new-httpd@hyperreal.com Cc: new-httpd@apache.org In-Reply-To: (message from Randy Terbush on Mon, 08 May 1995 10:08:02 -0500) Subject: Re: Log file and databases Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Date: Mon, 08 May 1995 10:08:02 -0500 From: Randy Terbush Precedence: bulk Reply-To: new-httpd@hyperreal.com CLF is too restrictive (we have said this before) It would be nice to be able to log *all* of the server request info into a database format. I have implemented a Perl-CGI approach and can log the CGI environment to dbm logfiles. However this requires the index.cgi approach in every directory. Hmmm... if external Perl code is involved, I'm not sure how requests which don't go through some external CGI script get logged. With some recent discussion regarding logging and security issues, would it not make sense to let the parent process running as root handle all of the logging? (non-forker) This would be a potential bottleneck. (Besides which, one nice feature of the current non-forking code is that the parent process, which runs as root, is not involved in handling transactions at all; this makes it simply impossible for skillfully constructed requests to abuse its privileges). Any comments on the system load that could be generated by the above mentioned index.cgi approach? If every transaction involves a CGI hit, it's *quite* severe, involving a fork *and exec* on each transaction. Related to the Perl-CGI approach, there is an interesting API developing that can spawn "Minisvr" processes to provide some statefulness to the session. Comments? Don't know about this. References? Should the logger be a separate program? I would prefer for it not to be --- it's more efficient to have the processes serving requests write whatever they would have written to the "separate logger" to a flat file instead, and to process the contents of that file off-line. rst