The following reply was made to PR mod_cgi/1291; it has been noted by GNATS.
From: Dave Shield <[EMAIL PROTECTED]>
To: Marc Slemko <[EMAIL PROTECTED]>
Cc: Dave Shield <[EMAIL PROTECTED]>,
Apache bugs database <[EMAIL PROTECTED]>
Subject: Re: mod_cgi/1291: CGI problems are reported as "Server problem -
contact the webmaster"
Date: Mon, 27 Oct 1997 16:58:56 +0000
> I'm not sure how your suggested change improves on this. All it does is
> give a different error message to the client which isn't much more
> informative from their point of view;
The default message is very similar, certainly.
But because it uses a different error code, the webmaster for the site
can configure the server to return a different error page, using the
ErrorDocument configuration option.
[local scenario re: developing CGI scripts]
> If someone is developing CGIs, then they should be smart enough to be able
> to look at the error log and see what it says.
That's fine for experienced CGI programmers, who can interpret the log
entries correctly. But we are teaching novice CGI programmers, who are
only just starting to learn the trade. I want to be able to point them
towards some useful hints (like running the debugging version of cgiwrap).
Maybe I'm just cynical after several years in University technical support,
but I suspect you have a higher opinion of students' abilities than I have.
(Don't be bitchy, Dave!)
> Your patch is useful in some cases, but it has the disadvantage of using
> up another status code which, at some point in the future, may cause
> conflicts
Fair comment.
I wouldn't have suggested it if you hadn't already used 506, which doesn't
appear in any HTTP standard I could see. I assumed it was an apache special.
> and of being quite limited; there are many many different errors
> that can cause a 500,
Yes, but very few (IMHO) that are likely to be the responsibility of anyone
other than the Web administrator. Which was the main impetus behind
distinguishing this one specially.
> What could be an option, however, is a config option that lets you have an
> error message similar to that which goes in the error log included in the
> internal error page. This would provide, in combination with an
> ErrorDocument and passing it in an environment variable, essentially the
> same net result without introducing something that is so specialized.
That would perhaps be useable, though it could be a bit messy to interpret
a general error string of that sort.
An alternative approach (perhaps in conjunction with the above) might be to
return "500 Internal error" throughout, but have an environmental variable
containing a simple (numeric?) "sub-error" code, to distinguish the various
causes of internal errors.
This could then be used by an ErrorDocument script to tailor the output
error page appropriately.
Being totally private to the implementation, it wouldn't be affected by
future extensions to the HTTP protocol.
Does this strike you as a plausible option?
Dave
