Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: Error log format configuration syntax
Date: Wed, 21 Jul 2010 23:35:08 +0200
User-Agent: KMail/1.13.3 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )
References: <alpine.DEB.1.10.1007200016170.23931@eru.sfritsch.de>
 <alpine.DEB.1.10.1007202059110.14215@eru.sfritsch.de>
 <4C472273.2050106@rowe-clan.net>
In-Reply-To: <4C472273.2050106@rowe-clan.net>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201007212335.08993.sf@sfritsch.de>

On Wednesday 21 July 2010, William A. Rowe Jr. wrote:
> On 7/20/2010 2:14 PM, Stefan Fritsch wrote:
> >> - 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)
> > 
> > ErrorLogFormat "[%{u}t] [%l] [pid %P^:tid %T^] ^%F: ^%E: ^[client
> > %a] ^%M ^, referer: %{Referer}i"
> 
> Outch - please evaluate using %^xxx instead.  I'd rather this were
> simply supported in a unified logging formatter, so it would apply
> to access, new log extensions, etc.  It could imply
> delete-adjacent non-whitespace unless there were multiple
> %-escapes in the same token.
> 
> I'm not fond of arbitrarily adding new escape codes, and we already
> had a suitable one (%).

We want a dedicated field separator, because only deleting adjacent 
non-whitespace wouldn't work for things like "[client %a]". I would 
prefer a single character as separator and have chosen '^' because it 
is relatively unlikely to appear literally in the log format. But I 
wouldn't mind using a two character separator. In this case, '%|' is 
probably more readable than '%^'.

And I agree that a unified logging formatter would be nice, but this 
is not something that will be done before 2.3.7 and it would likely 
mean an incompatible API change for modules providing handlers for 
mod_log_config. IMHO, this can wait until 3.0.