Mailing List Archive

Configurable logging formats... EXPERIMENTAL module.
I've been playing around for the last few hours with a configurable
logging module (i.e., a replacement for mod_log_common which accepts a
LogFormat directive in addition to TransferLog). This is still quite
experimental code --- it *seems* to work in my test VirtualHost (well,
main host and 'localhost') configuration, but I don't quite have
enough confidence in it to run with it on the main server yet. (FWIW,
a crude sanity check --- 'GET /index.html' a hundred times --- didn't
seem to show much a performance hit, though there's always the chance
I screwed up doing the test; also, testing the module did uncover a
one-line thinko in http_protocol.c; see next note).

Assuming I gain enough confidence in it tomorrow to run the thing
myself, there are a few things we could do with it:

1) Reject the thing outright, if it isn't what people want. I won't
be crushed --- it represents about six hours worth of work to date, tops.

2) Put it off until after current customer ship.

3) Release it as "experimental and unsupported", but as an indication
of future directions, and as something which people who are
interested in new and better logging solutions might want to play
with.

Anyway, the LogFormat directive is along the same basic lines I
remember people talking about; the LogFormat which reproduces CLF is

LogFormat "%h %l %u %t \"%r\" %s %b"

(those being host, logname, user, time, request, status, bytes-sent).

In addition to these, you can ask for %{Foobar}i and %{Foobar}o, to
get at the contents of some request or response MIME header,
respectively (e.g., you can use %{Referer}i to get the Referer).
Also, you can conditionalize the appearance of certain fields by HTTP
status code; for instance, '%!200,304,302{Referer}i' logs Referer only
on requests which got some sort of nontrivial error, and a '-'
otherwise to keep parsing sane. (This might be useful if your main
use for Referer: is tracking down pages with bogus links to your site,
and you don't want it taking up space otherwise --- in fact,
%404{Referer}i might be what some people really want; file not found
*only*).

To repeat, I am not wedded to this syntax, to the code, or to anything
at all about this really --- and I don't consider this to be in final
form in any case. (More formatting directives for URI, filename,
etc., are an obvious and easy addition, for example --- I'm just too
damn lazy for the moment). I wrote it mainly because if people really
are going down the path of lots of separate log files (which the
module structure does, unfortunately, tend to make easy), it might be
interesting to at least look at an alternative.

rst

PS --- people who want to look at the code, with caveats that it
probably still has a lurking bug or two, can find it at
ftp://ftp.ai.mit.edu/pub/users/rst/mod_log_config.c.
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
I would love to marry this with mod_cookie.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
On Sat, 29 Jul 1995, Robert S. Thau wrote:
> I've been playing around for the last few hours with a configurable
> logging module (i.e., a replacement for mod_log_common which accepts a
> LogFormat directive in addition to TransferLog). This is still quite
> experimental code --- it *seems* to work in my test VirtualHost (well,
> main host and 'localhost') configuration, but I don't quite have
> enough confidence in it to run with it on the main server yet.

Testing it now on port 8001 on hyperreal (conf file
/usr/local/www.tools/apache/conf/httpd.conf.s for those interested).
Apparently there's a bug in that an extra copy of every request
gets logged to SERVER_ROOT/logs/access_log, for both virtual and
non-virtual hosts.

> 3) Release it as "experimental and unsupported", but as an indication
> of future directions, and as something which people who are
> interested in new and better logging solutions might want to play
> with.

Yup, I would support this! +1

> Anyway, the LogFormat directive is along the same basic lines I
> remember people talking about; the LogFormat which reproduces CLF is
>
> LogFormat "%h %l %u %t \"%r\" %s %b"
>
> (those being host, logname, user, time, request, status, bytes-sent).

There's just a few more I'd like to add:

%U for unix time format
%a for actual object retreived when it differs from the object requested
- the heuristics for this need defining I suppose.
%T for total time to deliver file, in milliseconds (okay, I'm dreaming,
shoot me)

Hmm. The rest seem to be covered by your %i and %o (brilliant!)

> In addition to these, you can ask for %{Foobar}i and %{Foobar}o, to
> get at the contents of some request or response MIME header,
> respectively (e.g., you can use %{Referer}i to get the Referer).
> Also, you can conditionalize the appearance of certain fields by HTTP
> status code; for instance, '%!200,304,302{Referer}i' logs Referer only
> on requests which got some sort of nontrivial error, and a '-'
> otherwise to keep parsing sane. (This might be useful if your main
> use for Referer: is tracking down pages with bogus links to your site,
> and you don't want it taking up space otherwise --- in fact,
> %404{Referer}i might be what some people really want; file not found
> *only*).

I like this, but there is one more condition I'd like to be able to test for
- file type. In our custom log_common we log referrers for every non-image
access, to save space and ease readability. If this is hard to do
efficiently it's not a big deal to me, I'll just hack around it, but it
might be something others want.

Oh, and we need to bring up the question of escaping again.... sigh.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
On Sat, 29 Jul 1995, Robert S. Thau wrote:
> I've been playing around for the last few hours with a configurable
> logging module (i.e., a replacement for mod_log_common which accepts a
> LogFormat directive in addition to TransferLog). This is still quite
> experimental code --- it *seems* to work in my test VirtualHost (well,
> main host and 'localhost') configuration, but I don't quite have
> enough confidence in it to run with it on the main server yet.

Testing it now on port 8001 on hyperreal (conf file
/usr/local/www.tools/apache/conf/httpd.conf.s for those interested).
Apparently there's a bug in that an extra copy of every request
gets logged to SERVER_ROOT/logs/access_log, for both virtual and
non-virtual hosts.

> 3) Release it as "experimental and unsupported", but as an indication
> of future directions, and as something which people who are
> interested in new and better logging solutions might want to play
> with.

Yup, I would support this! +1

> Anyway, the LogFormat directive is along the same basic lines I
> remember people talking about; the LogFormat which reproduces CLF is
>
> LogFormat "%h %l %u %t \"%r\" %s %b"
>
> (those being host, logname, user, time, request, status, bytes-sent).

There's just a few more I'd like to add:

%U for unix time format
%a for actual object retreived when it differs from the object requested
- the heuristics for this need defining I suppose.
%T for total time to deliver file, in milliseconds (okay, I'm dreaming,
shoot me)

Hmm. The rest seem to be covered by your %i and %o (brilliant!)

> In addition to these, you can ask for %{Foobar}i and %{Foobar}o, to
> get at the contents of some request or response MIME header,
> respectively (e.g., you can use %{Referer}i to get the Referer).
> Also, you can conditionalize the appearance of certain fields by HTTP
> status code; for instance, '%!200,304,302{Referer}i' logs Referer only
> on requests which got some sort of nontrivial error, and a '-'
> otherwise to keep parsing sane. (This might be useful if your main
> use for Referer: is tracking down pages with bogus links to your site,
> and you don't want it taking up space otherwise --- in fact,
> %404{Referer}i might be what some people really want; file not found
> *only*).

I like this, but there is one more condition I'd like to be able to test for
- file type. In our custom log_common we log referrers for every non-image
access, to save space and ease readability. If this is hard to do
efficiently it's not a big deal to me, I'll just hack around it, but it
might be something others want.

Oh, and we need to bring up the question of escaping again.... sigh.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
Date: Sat, 29 Jul 1995 22:07:35 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>
Cc: new-httpd@mail.apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com


I would love to marry this with mod_cookie.

%{Cookie}i. Whassaproblem?

rst
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
Date: Sat, 29 Jul 1995 22:07:35 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>
Cc: new-httpd@mail.apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com


I would love to marry this with mod_cookie.

%{Cookie}i. Whassaproblem?

rst
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
Date: Sat, 29 Jul 1995 22:57:53 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>

Testing it now on port 8001 on hyperreal (conf file
/usr/local/www.tools/apache/conf/httpd.conf.s for those interested).
Apparently there's a bug in that an extra copy of every request
gets logged to SERVER_ROOT/logs/access_log, for both virtual and
non-virtual hosts.

Are you sure you remembered to take mod_log_common out? If you don't,
it will still be there, but it won't be configured (mod_log_config
gets all the TransferLog commands), so you'll get its default
behavior, which is as described.

> Anyway, the LogFormat directive is along the same basic lines I
> remember people talking about; the LogFormat which reproduces CLF is
>
> LogFormat "%h %l %u %t \"%r\" %s %b"
>
> (those being host, logname, user, time, request, status, bytes-sent).

There's just a few more I'd like to add:

%U for unix time format

Ummm... given %u for user, it would probably be better for %U to be
URI. (Then, with the current code, %<U would be URI requested, as
modified by MultiViews, and %>U would be URI delivered --- the '<' and
'>' select original or final request, and are in the code, but not
written up; %U itself would be trivial to add (<5 lines)).

As for this, it might be better to have a %{...}t option, where the
{...}, if present, is a time format string. This isn't very hard, and
it does avoid consuming the (one-character) namespace.

%a for actual object retreived when it differs from the object requested
- the heuristics for this need defining I suppose.

See above for my thoughts on this.

%T for total time to deliver file, in milliseconds (okay, I'm dreaming,
shoot me)

This would require a record of arrival time in the request structure
(not the connection --- think keep-alives and HTTP-NG), so I'd rather
not do it for this release. For the public release *after* next, this
is easy and probably worthwhile.

Hmm. The rest seem to be covered by your %i and %o (brilliant!)

They cover a lot of things. Less code to write...

> In addition to these, you can ask for %{Foobar}i and %{Foobar}o, to
> get at the contents of some request or response MIME header,
> respectively (e.g., you can use %{Referer}i to get the Referer).
> Also, you can conditionalize the appearance of certain fields by HTTP
> status code; for instance, '%!200,304,302{Referer}i' logs Referer only
> on requests which got some sort of nontrivial error, and a '-'
> otherwise to keep parsing sane. (This might be useful if your main
> use for Referer: is tracking down pages with bogus links to your site,
> and you don't want it taking up space otherwise --- in fact,
> %404{Referer}i might be what some people really want; file not found
> *only*).

I like this, but there is one more condition I'd like to be able to test for
- file type. In our custom log_common we log referrers for every non-image
access, to save space and ease readability. If this is hard to do
efficiently it's not a big deal to me, I'll just hack around it, but it
might be something others want.

Geez. I thought people might want to conditionalize on originating
host (I think NetSite allows this), but file type is a new one on me.
It's reasonable, though. To make it work, I think we'd really need a
worked-out syntax for multiple types of conditions ---

%[Status=404]{Referer}i
%[Status!=200,304,302]{Referer}i
%[Content-type!~image/]{Referer}i

...and then we'd need to worry about syntaxes (and semantics) for
combinations --- AND about dealing with LogFormat directives which
are large enough to be most conveniently put on multiple lines.
(The cmd_parms structure does allow a command handler to read
additional lines out of the config file, if it *really* wants to;
<LogFormat> sections, anyone?)

Oh, and we need to bring up the question of escaping again.... sigh.

Yep. There is no auto-escaping on anything in the current version;
all delimiters have to be literally present in the LogFormat string.
I take it you noticed what I said in the block comment up top of the
code on this issue, but for those who haven't looked yet:

* Note that
* there is no escaping performed on the strings from %r, %...i and
* %...o; some with long memories may remember that I thought this was
* a bad idea, once upon a time, and I'm still not comfortable with
* it, but it is difficult to see how to "do the right thing" with all
* of '%..i', unless we URL-escape everything and break with CLF.

FWIW, making %@x URL-escape the result of %x, for all x, would again
be just a few lines of code...

rst
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
Date: Sat, 29 Jul 1995 22:57:53 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>

Testing it now on port 8001 on hyperreal (conf file
/usr/local/www.tools/apache/conf/httpd.conf.s for those interested).
Apparently there's a bug in that an extra copy of every request
gets logged to SERVER_ROOT/logs/access_log, for both virtual and
non-virtual hosts.

Are you sure you remembered to take mod_log_common out? If you don't,
it will still be there, but it won't be configured (mod_log_config
gets all the TransferLog commands), so you'll get its default
behavior, which is as described.

> Anyway, the LogFormat directive is along the same basic lines I
> remember people talking about; the LogFormat which reproduces CLF is
>
> LogFormat "%h %l %u %t \"%r\" %s %b"
>
> (those being host, logname, user, time, request, status, bytes-sent).

There's just a few more I'd like to add:

%U for unix time format

Ummm... given %u for user, it would probably be better for %U to be
URI. (Then, with the current code, %<U would be URI requested, as
modified by MultiViews, and %>U would be URI delivered --- the '<' and
'>' select original or final request, and are in the code, but not
written up; %U itself would be trivial to add (<5 lines)).

As for this, it might be better to have a %{...}t option, where the
{...}, if present, is a time format string. This isn't very hard, and
it does avoid consuming the (one-character) namespace.

%a for actual object retreived when it differs from the object requested
- the heuristics for this need defining I suppose.

See above for my thoughts on this.

%T for total time to deliver file, in milliseconds (okay, I'm dreaming,
shoot me)

This would require a record of arrival time in the request structure
(not the connection --- think keep-alives and HTTP-NG), so I'd rather
not do it for this release. For the public release *after* next, this
is easy and probably worthwhile.

Hmm. The rest seem to be covered by your %i and %o (brilliant!)

They cover a lot of things. Less code to write...

> In addition to these, you can ask for %{Foobar}i and %{Foobar}o, to
> get at the contents of some request or response MIME header,
> respectively (e.g., you can use %{Referer}i to get the Referer).
> Also, you can conditionalize the appearance of certain fields by HTTP
> status code; for instance, '%!200,304,302{Referer}i' logs Referer only
> on requests which got some sort of nontrivial error, and a '-'
> otherwise to keep parsing sane. (This might be useful if your main
> use for Referer: is tracking down pages with bogus links to your site,
> and you don't want it taking up space otherwise --- in fact,
> %404{Referer}i might be what some people really want; file not found
> *only*).

I like this, but there is one more condition I'd like to be able to test for
- file type. In our custom log_common we log referrers for every non-image
access, to save space and ease readability. If this is hard to do
efficiently it's not a big deal to me, I'll just hack around it, but it
might be something others want.

Geez. I thought people might want to conditionalize on originating
host (I think NetSite allows this), but file type is a new one on me.
It's reasonable, though. To make it work, I think we'd really need a
worked-out syntax for multiple types of conditions ---

%[Status=404]{Referer}i
%[Status!=200,304,302]{Referer}i
%[Content-type!~image/]{Referer}i

...and then we'd need to worry about syntaxes (and semantics) for
combinations --- AND about dealing with LogFormat directives which
are large enough to be most conveniently put on multiple lines.
(The cmd_parms structure does allow a command handler to read
additional lines out of the config file, if it *really* wants to;
<LogFormat> sections, anyone?)

Oh, and we need to bring up the question of escaping again.... sigh.

Yep. There is no auto-escaping on anything in the current version;
all delimiters have to be literally present in the LogFormat string.
I take it you noticed what I said in the block comment up top of the
code on this issue, but for those who haven't looked yet:

* Note that
* there is no escaping performed on the strings from %r, %...i and
* %...o; some with long memories may remember that I thought this was
* a bad idea, once upon a time, and I'm still not comfortable with
* it, but it is difficult to see how to "do the right thing" with all
* of '%..i', unless we URL-escape everything and break with CLF.

FWIW, making %@x URL-escape the result of %x, for all x, would again
be just a few lines of code...

rst
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
On Sun, 30 Jul 1995, Robert S. Thau wrote:

> Date: Sat, 29 Jul 1995 22:07:35 -0700 (PDT)
> From: Brian Behlendorf <brian@organic.com>
> Cc: new-httpd@mail.apache.org
> Precedence: bulk
> Reply-To: new-httpd@hyperreal.com
>
>
> I would love to marry this with mod_cookie.
>
> %{Cookie}i. Whassaproblem?

the cookies need to be "set" on first access.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
On Sun, 30 Jul 1995, Robert S. Thau wrote:
> Date: Sat, 29 Jul 1995 22:57:53 -0700 (PDT)
> From: Brian Behlendorf <brian@organic.com>
>
> Testing it now on port 8001 on hyperreal (conf file
> /usr/local/www.tools/apache/conf/httpd.conf.s for those interested).
> Apparently there's a bug in that an extra copy of every request
> gets logged to SERVER_ROOT/logs/access_log, for both virtual and
> non-virtual hosts.
>
> Are you sure you remembered to take mod_log_common out? If you don't,
> it will still be there, but it won't be configured (mod_log_config
> gets all the TransferLog commands), so you'll get its default
> behavior, which is as described.

D'oh! Good call :) I'll get this thing soon. Consider this a dry run
for false bug reports :)

> > Anyway, the LogFormat directive is along the same basic lines I
> > remember people talking about; the LogFormat which reproduces CLF is
> >
> > LogFormat "%h %l %u %t \"%r\" %s %b"
> >
> > (those being host, logname, user, time, request, status, bytes-sent).
>
> There's just a few more I'd like to add:
>
> %U for unix time format
>
> Ummm... given %u for user, it would probably be better for %U to be
> URI. (Then, with the current code, %<U would be URI requested, as
> modified by MultiViews, and %>U would be URI delivered --- the '<' and
> '>' select original or final request, and are in the code, but not
> written up; %U itself would be trivial to add (<5 lines)).
>
> As for this, it might be better to have a %{...}t option, where the
> {...}, if present, is a time format string. This isn't very hard, and
> it does avoid consuming the (one-character) namespace.

Works for me! As long as that's not too expensive.

> %a for actual object retreived when it differs from the object requested
> - the heuristics for this need defining I suppose.
>
> See above for my thoughts on this.
>
> %T for total time to deliver file, in milliseconds (okay, I'm dreaming,
> shoot me)
>
> This would require a record of arrival time in the request structure
> (not the connection --- think keep-alives and HTTP-NG), so I'd rather
> not do it for this release. For the public release *after* next, this
> is easy and probably worthwhile.

Okay.

> Hmm. The rest seem to be covered by your %i and %o (brilliant!)
>
> They cover a lot of things. Less code to write...
>
> > In addition to these, you can ask for %{Foobar}i and %{Foobar}o, to
> > get at the contents of some request or response MIME header,
> > respectively (e.g., you can use %{Referer}i to get the Referer).
> > Also, you can conditionalize the appearance of certain fields by HTTP
> > status code; for instance, '%!200,304,302{Referer}i' logs Referer only
> > on requests which got some sort of nontrivial error, and a '-'
> > otherwise to keep parsing sane. (This might be useful if your main
> > use for Referer: is tracking down pages with bogus links to your site,
> > and you don't want it taking up space otherwise --- in fact,
> > %404{Referer}i might be what some people really want; file not found
> > *only*).
>
> I like this, but there is one more condition I'd like to be able to test for
> - file type. In our custom log_common we log referrers for every non-image
> access, to save space and ease readability. If this is hard to do
> efficiently it's not a big deal to me, I'll just hack around it, but it
> might be something others want.
>
> Geez. I thought people might want to conditionalize on originating
> host (I think NetSite allows this), but file type is a new one on me.
> It's reasonable, though. To make it work, I think we'd really need a
> worked-out syntax for multiple types of conditions ---
>
> %[Status=404]{Referer}i
> %[Status!=200,304,302]{Referer}i
> %[Content-type!~image/]{Referer}i
>
> ...and then we'd need to worry about syntaxes (and semantics) for
> combinations --- AND about dealing with LogFormat directives which
> are large enough to be most conveniently put on multiple lines.
> (The cmd_parms structure does allow a command handler to read
> additional lines out of the config file, if it *really* wants to;
> <LogFormat> sections, anyone?)
>
> Oh, and we need to bring up the question of escaping again.... sigh.
>
> Yep. There is no auto-escaping on anything in the current version;
> all delimiters have to be literally present in the LogFormat string.
> I take it you noticed what I said in the block comment up top of the
> code on this issue, but for those who haven't looked yet:
>
> * Note that
> * there is no escaping performed on the strings from %r, %...i and
> * %...o; some with long memories may remember that I thought this was
> * a bad idea, once upon a time, and I'm still not comfortable with
> * it, but it is difficult to see how to "do the right thing" with all
> * of '%..i', unless we URL-escape everything and break with CLF.
>
> FWIW, making %@x URL-escape the result of %x, for all x, would again
> be just a few lines of code...

Lots of good ideas here - are you sure you didn't help Larry Wall write
Perl? :)

I think we should see how far we can go without significantly affecting
performance - we still have the TransferLog "|program" option for really
complex stuff, so AND'ed conditionals and such might not be that crucial.
Hmm.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
Date: Sun, 30 Jul 1995 11:46:29 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>

>
> %{Cookie}i. Whassaproblem?

the cookies need to be "set" on first access.

...and you still need mod_cookie to do that (or at least the fixup
half of it), but once that's done, then this should log it just fine.
(Hmmm... or will it? To get the outgoing cookie on the first request,
you'd need to look at %{Set-cookie}o as well... ooops).

rst
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
Date: Sun, 30 Jul 1995 11:52:19 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>

> As for this, it might be better to have a %{...}t option, where the
> {...}, if present, is a time format string. This isn't very hard, and
> it does avoid consuming the (one-character) namespace.

Works for me! As long as that's not too expensive.

It's using strftime() anyway to format the time; this just means
plugging in a user-supplied format string as the argument.
(Unfortunately, this can't give you the timezone in CLF timezone
format --- [+-]HHMM --- because there is no strftime directive for
that; the best you can get out of strftime itself is a timezone
abbreviation. Both mod_log_common and mod_log_config have
special-case code for this).

Lots of good ideas here - are you sure you didn't help Larry Wall write
Perl? :)

Quite sure. If I had, I like to think Perl scripts would look a
little less like you had taken code written in an otherwise sensible
programming language and left them at the bottom of a chicken coop for
a couple of hours...

I think we should see how far we can go without significantly affecting
performance - we still have the TransferLog "|program" option for really
complex stuff, so AND'ed conditionals and such might not be that crucial.
Hmm.

I think we can probably go pretty far with the "you don't pay for what
you don't use" theory --- just make sure that the complex conditions,
etc., are implemented in such a way that they don't cause any run-time
overhead if they don't actually occur in the format string (or
whatever). NB that in the mod_log_config experiment, there is a quick
short-circuit around the condition code stuff if there are no
directives on a particular directive...

rst
Re: Configurable logging formats... EXPERIMENTAL module. [ In reply to ]
From: rst@ai.mit.edu (Robert S. Thau)
Date: Sun, 30 Jul 95 18:25:09 EDT

...and you still need mod_cookie to do that (or at least the fixup
half of it), but once that's done, then this should log it just fine.
(Hmmm... or will it? To get the outgoing cookie on the first request,
you'd need to look at %{Set-cookie}o as well... ooops).

Hmmm... then again, looking at mod_cookies, it seems to have the same
bug itself (not logging the cookie for the transaction which generated
it initially, which means you lose the first step of the clicktrail).

One (ugly, but workable) way to get around this, and make the cookie
available to scripts as well, by having make_cookie put the new cookie
onto r->headers_in, in effect faking a Cookie: header from the client.
This would make %{Cookie}i work in all cases as well.

rst