There are a number of error messages that I find myself explaining a
dozen times a day. "That means ..."
For example, the "has no VirtualHosts" message hardly ever means that
there are no virtualhost, but rather than there's more than one
NameVirtualHost line, or that the virtual hosts don't match the
NameVirtualHost line.
So, this got me thinking, and I have two questions.
1) How long is too long for an error message? For example is something
like this too much:
Index: vhost.c
===================================================================
--- vhost.c (revision 934954)
+++ vhost.c (working copy)
@@ -507,7 +507,7 @@
if (ic->server == NULL) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, main_s,
- "NameVirtualHost %s:%u has no VirtualHosts",
+ "Either NameVirtualHost %s:%u has no
VirtualHosts, or there is more than one identical NameVirtualHost
line, or your VirtualHost declarations do not match the
NameVirtualHost line",
ic->sar->virthost, ic->sar->host_port);
*pic = ic->next;
}
2) Is there still opposition to putting URLs in error messages? What I
imagine is a series of tiny single-purpose web pages that do nothing
more than explain single error messages. So in this case, we'd have a
page that has the error message, and explains the three possible
causes of the error message, and how you'd fix each one. The error
message itself would contain a URL to that page, IN ADDITION TO the
message that's already there. That is, folks that for whatever reason
don't have net access at the moment are no worse off than they would
already have been had we not added this, so if the site goes down,
they're not completely at a loss as to what happened.
This solution has the benefit of a fully detailed explanation, but
also has the problem that the URLs would tend to be fairly long, such
as http://httpd.apache.org/docs/2.2/errors/no_vhosts.html
3) I suppose a third alternative is to log an additional message, if
we're in LogLevel Debug, that has the detailed information. Hmm. That
might be worth pursuing all by itself, even if the other two
alternatives don't pan out.
--
Rich Bowen
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
