Changing error messages

[Charles Blair]

From: Thomas Dowling <tdowling at ohiolink.ohiolink.edu>
Subject: Re: Changing error messages
Date: Mon, 4 Dec 1995 15:00:49 -0800

> With NCSA httpd, you only have to edit a couple of lines in the
> srm.conf file, make a nicely worded HTML file in the appropriate
> place, and restart httpd; if you prefer, you can point to a CGI
> script instead.  It takes about three minutes of looking at the
> configuration files and documentation to find this out.

I think it takes more than three minutes, unless one has set up the
Web server oneself and _remembers_ where to start looking; at a busy
site like ours, where system administrators do much more than just
administer Web servers (such as security, upgrading software, keeping
legacy information systems such as the gopher in operation,
etc. etc. etc.), the act of remembering usually chews up the first
three minutes. :-) But that's beside the point.

Unless _all_ web administrators do this, I wonder whether it will
solve the general problem. Also, unless a site sends me back the
number and/or the standard prose together with the new prose (I
haven't tested to see if changing srm.conf for NCSA httpd will only
send back the new prose), I wonder whether I'll know what the error
was, unless we have standards for the prose. ("110" is a bit cryptic,
but it tells me more than just "author.") The numbers, at least, can
be looked up, not by the end-user, but by someone, who can then craft
a web document for a local site that explains what the various error
messages mean.

At our site we've just implemented a URL-checker, which mails to web
authors a list of URLs in the pages they maintain that have
problems. But in addition to the reports we send out, we put up on our
staff web a companion document that explains all the error messages in
plain English. The messages are those returned to the URL-checker by
both our and off-site servers. This doesn't help an end-user surfing
the net, but it helps us understand how to maintain our own webs
despite cryptic error messages, and perhaps will eventually help our
web authors understand the messages they get back when they surf.