httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Bowen <>
Subject Error messages
Date Fri, 16 Apr 2010 15:25:04 GMT
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  

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

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

View raw message