httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: bug in mod_cgi (sends 200 instead of 500)
Date Sat, 18 Jan 2003 01:30:15 GMT
André Malo wrote:
> * Stas Bekman wrote:
>>It shows that I haven't run mod_cgi for ages. I was just used to having
>>this as a failure (500) under mod_perl. Any reason for not checking the
>>return status?
> hmm, performance? memory usage? What about a script that throws out a lot 
> of data (say, 1 MB, multiplied with $number_of_instances) and then dies 
> with "could not read last record from file"? How does mod_perl handle such 
> cases?

OK, I see that my question was improper. 200 is indeed OK, because you 
don't buffer up the data before you know the return status.

What I was missing is the error message attached to the end of the normal 
output to indicate that there was a problem (better late than never).

e.g. the following script:

#!/usr/bin/perl -w
print "Content-type: text/plain\n\n";
print "Should be printed";
print no_such_func();
print "Shouldn't be printed";

Under mod_cgi, it'll print only:

Should be printed

whereas under mod_perl, it'll print:

Should be printed
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<TITLE>Server error!</TITLE>
and the rest of the error message.

because mod_perl checks the return status and sends the error message 
through if there is one. This gives an indication to the developer that 
something went wrong. Unfortunately too few developers remember to check 
the error_log file for errors.

Indeed apache-1.3's mod_cgi behaves identicallly to 2.0's mod_cgi.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message