www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: mod_cgi/1291: CGI problems are reported as "Server problem - contact the webmaster"
Date Mon, 27 Oct 1997 16:10:01 GMT
The following reply was made to PR mod_cgi/1291; it has been noted by GNATS.

From: Marc Slemko <marcs@znep.com>
To: Dave Shield <D.T.Shield@csc.liv.ac.uk>
Cc: Apache bugs database <apbugs@apache.org>
Subject: Re: mod_cgi/1291: CGI problems are reported as "Server problem -  contact the webmaster"
Date: Mon, 27 Oct 1997 09:05:25 -0700 (MST)

 On Mon, 27 Oct 1997, Dave Shield wrote:
 
 >     [I'll resend this, as the original seems to have got lost]
 > 
 > > Synopsis: CGI problems are reported as "Server problem - contact the webmaster"
 > > 
 > > State-Changed-From-To: open-feedback
 > > State-Changed-By: coar
 > > State-Changed-When: Tue Oct 21 08:03:46 PDT 1997
 > > State-Changed-Why:
 > > As far as the external user is concerned, the problem is
 > > with a service the Web server is providing - so the
 > > error is appropriate.
 > 
 > This is an assumption that may not necessarily be correct in a particular
 > situation.
 >   As far as the external user is concerned, something went wrong and they
 > need to be able to report it to the appropriate person - they don't really
 > care who.  Ideally, this should be the person who actully maintains the CGI
 > script, who need not be the overall webmaster  (otherwise the webmaster has
 > to determine who's responsible, and pass on the comment - all extra work).
 
 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; they don't care if it is a CGI or
 some other error.
 
 > 
 >   With the apache server as distributed, it isn't possible to make this
 > distinction.   The patch I offer (appended) allows this to be configured,
 > thus allowing this possibility if a particular site so chooses.
 > 
 >   The other time this is useful is when a server is being used to teach
 > CGI programming.  In this situation, the "external user" is likely to be
 > the person writing the script - in which case they do need to know that
 > the CGI went wrong, rather than a "real" server error.
 >   This is the scenario that led to the development of this patch here.
 > The webmasters were getting a steady stream of "server problem" reports,
 > which all stemmed from minor CGI errors.  By distinguishing these two cases,
 > we are able to provide a "CGI error" web page, which includes advice on
 > identifying and solving the problem.
 
 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.  
 
 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 and of being quite limited; there are many many different errors
 that can cause a 500, and if you start having a seperate error code for
 each it just gets unworkable.
 
 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.
 This has been considered but no finished implementation has been submitted
 yet.
 

Mime
View raw message