André Malo wrote:
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.* 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?
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">
<HTML>
<HEAD>
<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
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
