From: "Joshua Slive" <[EMAIL PROTECTED]> Sent: Sunday, December 30, 2001 11:53 AM
> > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > > > 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
