httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: error numbers
Date Fri, 09 Mar 2012 13:16:58 GMT
On 09.03.2012 02:21, Rich Bowen wrote:
> On Mar 8, 2012, at 7:01 PM, Daniel Ruggeri wrote:
>> On 3/8/2012 12:29 PM, Mathijs wrote:
>>> I have extracted some info from source that might be useful, somebody
>>> with more awk/grep/perl fu then me can probably combine it into a
>>> sensible format:
>>> (has some dodgy matches but
>>> at least most strings are there)
>> These come from source, but isn't it reasonable to assume that the user
>> got the error number and text when the compiled code threw the error
>> that is in the source code? I think the community would be better served
>> by providing supplemental documentation aside from the error string they
>> already received.
>> Something along the lines of:
>> ErrNo: 01961
>> Proxy is pointed to a backend that starts with scheme "https" but the
>> SSLProxyEngine has not been enabled. Enabled the SSLProxyEngine by
>> adding "SSLProxyEngine On" or change "https" to "http" in the
>> BalancerMember, RewriteRule, ProxyPass or ProxyPassMatch directive.
> Yes, that is indeed the intent of this effort. The generated text files
> were merely a starting point from which to work.
>> For a person who has seen the error before, the log entry itself is
>> succinct enough to be clear, but for someone who hasn't, this more
>> verbose description should help them zero in on what needs to be changed
>> for this to work right.
>> Am I on target with others' expectations? If so, maybe we should take
>> these two lists and start a catalog of what errors need more information
>> and which are sufficient as they are.
> Yep

AFAIR the log tags were motivated by Stefan in order to be able to 
exactly identify a certain message, e.g. when doing a search on a search 
engine. The plan is *not* to reduce to reduce the logging down to the 
log tag and leave module name, message string and all the other nice 
info out, because you could look it up in the docs.

The primary goal, finding traces of similar log errors in the net should 
be satisfied by the tag itself. Using the tags as an index into a more 
detailed description of log errors is fine, but we won't be able to do 
it for most messages - there are to many.

I wonder whether such info would fit into the wiki?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message