Home > Guardian Error Handling System > Help > 1021

CGI errors that cannot be processed by Guardian

Guardian is only triggered for unhandled CGI script errors.

CGI scripts are interactive applications. As such, they can communicate success or error information to users. When they communicate error information in a controlled way, this is a handled error and Guardian is not involved.

Example of an error that triggers Guardian

Consider the code:

#!/usr/bin/perl --

my $secret_number = 1 / 0;

print "Content-Type: text/html\n\n";
if ($secret > 0) {
	print "Success: positive!\n";
	}
else {
	print "Error: not positive!\n";
	}

In this example, the Perl interpreter will get to the second line of code and see the illegal 1/0 division. The Perl interpreter will exit with the fatal error "Illegal division by zero". The web server will see that 1) the CGI script did not print a valid Content-Type header and 2) exited with an error code. The web server will therefore assign the status code "500 Internal Server Error" and then pass control to the 500 ErrorDocument handler, Guardian.

Example of an error that does not trigger Guardian

Consider the code:

#!/usr/bin/perl --

my $secret_number = 1 / -1;

print "Content-Type: text/html\n\n";
if ($secret > 0) {
	print "Success: positive!\n";
	}
else {
	print "Error: not positive!\n";
	}

In this example, there are no Perl errors. The $secret_number evaluates as -1, and so the script prints "Error: not positive!".

As far as the web server is concerned, this CGI script executed successfully because 1) it returned a valid Content-Type header and 2) did not exit with an error code. Guardian will not be triggered.

Compatibility with high-level script interpreters

Many web-based scripting languages like PHP, ASP, and Cold Fusion use an in-memory script interpreter to handle requests. The interpreter acts as a filter between the web server and the script file. The filter is free to override error status and often does.

For these languages, even if the actual script file suffers an unhandled error, the in-memory interpreter will catch the error and handle it. Typically, a specially-formatted error page is created, listing the line number where the error occurred and the language-specific error information. When the in-memory interpreter handles the error, the web server will treat the request as a success and will not trigger Guardian.

Oftentimes these script interpreters have their own proprietary ways to customize error handling behavior. For example, Microsoft IIS uses the 500 error code for CGI errors and the 500;100 error code for ASP errors.

Consistent error handling

Most webmasters want all of their interactive systems to use the same layout, for both success and error responses, and to log errors in a consistent way. This is a noble goal. Unfortunately, the only way to achieve that goal is to customize each interactive system, which can be labor-intensive. Guardian is not able to automatically catch all application-specific errors. It only catches webserver-specific errors.


    "CGI errors that cannot be processed by Guardian"
    http://www.xav.com/scripts/guardian/help/1021.html