httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Error log format configuration syntax
Date Wed, 21 Jul 2010 09:23:50 GMT
On 20.07.2010 21:14, Stefan Fritsch wrote:
> On Tue, 20 Jul 2010, Rainer Jung wrote:
>> message and behind the message. I guess you can get rid of the latter
>> split by assigning a format specifier also to the log message, like
>> '%M' or similar, and then
>> ErrorLogFormat "[%{u}t] [%l] [pid %P%{:tid }T] %F: %{}{: }E%{[client
>> }{] }a %M %{}{, referer: }i"
> Doing it with two config directives was more straightforward to
> implement, but I agree that the configuration would be easier to read
> with a format specifier for the log message.
>> Maybe questioning, how important the configurable pre and suffixes
>> are. We could either provide fixed ones for the individual log
>> patterns, or we could provide none and indeed log an empty string or
>> "-" if we don't have a value. I'd say both ways are viable. I guess
>> some users would find it nice to have a fixed column format until the
>> error message begins, so it's easier to parse by script, others will
>> find it more readable if the empty fields get suppressed (condensed
>> format).
>> What about:
>> - Allow to choose whether empty values get dropped (one configuration
>> switch to choose the condensed format)
>> - taking all adjacent non-whitespace as prefixes and suffixes,
>> collapse resulting adjacent whitespace in the output by adding the
>> whitespace in front of the prefix to the prefix and dropping leading
>> whitespace from the resulting line)
> Thats a very interesting idea. Taking it one step further, one could
> introduce a meta-character (e.g. ^) for separating the fields. If a
> format specifier produces no output, everything from the previous to the
> next field separator gets deleted. For example:
> ErrorLogFormat "[%{u}t] [%l] [pid %P^:tid %T^] ^%F: ^%E: ^[client %a]
> ^%M ^, referer: %{Referer}i"
> That's quite readable. I will check how much effort this is to implement.

Yes, that way the choice between condensed and keeping empty fields is 
also back to users. If they mark a prefix or a suffix they get it 
removed, if not it will stay always (and we could print "-" for the 
missing data).



View raw message