From: Rob Hartill <hartill@ooo.lanl.gov>
Message-Id: <9503170312.AA14596@ooo.lanl.gov>
Subject: Re: Customizable logging
To: new-httpd@hyperreal.com
Date: Thu, 16 Mar 95 20:12:31 MST
In-Reply-To: <199503170247.SAA02322@neon.netscape.com>;
 from "Rob McCool" at Mar 16, 95 6:47 pm
Organization: Theoretical Division, T-8. Los Alamos National Laboratory
Address: LANL Theoretical Divi' T-8, MS B285, P.O Box 1663,
 Los Alamos NM 87545
Fax: (505) 667 5585
Phone: (505) 665-2280 or 667-5336 (T-8 Secretary)
Mailer: Elm [revision: 70.85]
Sender: owner-new-httpd@hyperreal.com
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

> 
> That might be interesting. I think you mean REQUEST_PROTOCOL, but I
> get the idea. How would you incorporate formatting hints into that
> format, or delimit fields? 

I don't see the problem - you'd first give the string to a
time function to replace the %x entries, then you'd start looking
for the HTTP/CGI variables - they'll all be   $[A-Z_]+  at this
point. Replace them, and whatever is left over is presumably what
the user wanted the output to look like; (s)he decides what 
field delimiters to use. One could also throw in a few "\n"s if
you wanted, thus making it a multiline per request log format.

By offering the users any output format they want, they can work
around any problem with delimiting characters appearing in the
fields, e.g. if you know that $BLEAH is going to produce a string
with spaces in it, and space is the field delimiter, then you simply
change the deilimter or wrap the offending field inside something
like [$BLEAH], "$BLEAH", {$BLEAH}  or whatever.

>I've considered using URL encoding to do
> it; URL-encode all of the fields before separating them with &
> characters. Or another reserved character like " ".

Yuck !  :-)   That'd be a giant step backwards in terms of readibility.