Mailing-List: contact docs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: docs@httpd.apache.org
Message-ID: <018b01c1915f$373782b0$95c0b0d0@v505>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: <dev@httpd.apache.org>,
	<docs@httpd.apache.org>
References: <ELEDJONBOPPAEGANDEEIGELLCAAA.joshua@slive.ca>
Subject: Re: Logs and logs and logs [oh my!]
Date: Sun, 30 Dec 2001 12:22:33 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Joshua Slive" <joshua@slive.ca>
Sent: Sunday, December 30, 2001 11:53 AM


> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> 
> > Isn't it time to drop TransferLog and CookieLog?
> 
> +1
> 
> > We can accomplish the same by allowing that LogFormat provides the default
> > for the CustomLog directive, in the absense of an optional [format] arg.
> 
> I haven't looked in detail, but I'm guessing that it won't work so easily,
> and might just be confusing.  I don't see any need to make CustomLog act
> like TransferLog.  If we are breaking backward compatibility, we might as
> well leave only the clearest stuff.

Right now, TransferLog is TAKE1, and CustomLog is TAKE23 ... so there is little
chance this breaks anything.  We turn this into TAKE123, and in the TAKE1 case,
we just 'borrow' the last (unnamed / default) LogFormat.  I believe it's goodness
to preserve the feature, just not in so many directives.

> > And if we offer a built-in (or default-config'ed) 'cookie' format,
> > of "%{Cookie}n \"%r\" %t", then it's a two bit change to turn a CookieLog
> > into a CustomLog file cookie command.
> 
> I wouldn't bother with a build-in format.  We can just document the
> necessary LogFormat directive.

Fair enough, we might as well just drop this into the list of other, optional
formats that describe older logs in our httpd-std.conf [and friends];

  LogFormat "%{Cookie}n \"%r\" %t" cookie

> The configuration will be simplest if we just drop TransferLog, CookieLog,
> and the one-argument format of LogFormat.  No functionality is lost and
> everything will be much clearer.

I agree it's simplest, but under my proposal, we lost no functionallity.
If we agree nobody uses the 'default' format TransferLog, then I'm fine with
your suggestion.  But I rather guess this is too radical, and some users
probably rely on a globally defined format, that is applied to TransferLogs
in many servers.  Anyone have additional thoughts?

Bill


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org