At 02:02 PM 4/18/00 +0100, Steve Hay wrote:
>I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl
>scripts.
Sorry for the late reply. I was actually trying to figure out why you were
experiencing this problem. I rarely use Perl 5.005 specific features, and
so I actually received reasonable results where you were not.
It turns out that CGI::Carp does a specific check for Perl 5.005 and above
and uses a different mechanism that asks whether it is in an eval block.
Unfortunately the $^S variable gives information that is not precisely the
same as the error string parsing (for "eval") technique in it's
effectiveness under mod_perl.
Of course, do take what I say with a grain of salt. I am NOT the author of
CGI::Carp. But I do like using it because it is more convenient than using
an outer eval block in every CGI script. I have emailed the author of
CGI::Carp with this issue today and hopefully should receive confirmation
or negation of this theory within the next few days unless others on here
can confirm or deny the rumors.
>Below are three short scripts and their output under Apache/CGI and
>Apache/modperl. All three of them produce (more or
>less) useful output under Apache/CGI, but only the last one does under
>Apache/modperl.
>
>The first one calls die() itself. Under Apache/CGI the die() message
>appears in the web browser (albeit preceded by a
>spurious Content-Type line), but under Apache/modperl the message goes
>to the error.log and a bizarre message appears in
>the web browser consisting of some output from the script, followed by a
>"200 OK" HTTP header, followed by a message
>suggesting that all was not OK after all (all the same as if CGI::Carp
>was not being used).
>
>The second one has a syntax error. Under Apache/CGI a message about a
>compilation error appears in the web browser (but not
>the detail of the syntax error itself, which disappears completely - not
>even going to error.log!); under Apache/modperl an
>"Internal Server Error" message appears in the web browser (again just
>like CGI::Carp was not being used) and (curiously)
>the detail of the syntax error does now at least appear in error.log!
>
>The third one attempts a division by zero and correctly says so in the
>web browser under both Apache/CGI and
>Apache/modperl.
>
>Can anybody explain what's going on here???
Yes. Albeit a little late. Sorry about that.
>The first script is closest to the problem I've really got. I'm using
>DBI/DBD::mysql and I want SQL syntax errors (which I
>keep making) to appear in the web browser instead of having to keep
>opening the error.log. Running under Apache/CGI I get
>useful messages like:
>
>Software error:
>DBD::mysql::st execute failed: You have an error in your SQL syntax near
>'BINARY USER_NAME LIKE 'mk-%' LIMIT 10' at line 1
>at d:/inetpub/cgi-bin/mysql.pl line 300.
>
>but under Apache/modperl I just get useless garbage like the
>error_die.pl below produces.
>
>I'm running Perl 5.005_03 / Apache 1.3.6 / mod_perl 1.22 on NT 4.
>
>
>error_die.pl
>------------
>
> use CGI::Carp qw(fatalsToBrowser);
> $| = 1;
> print "Content-Type: text/html\n\n";
> print "I'm about to die() ...\n";
> die "I'm dead.\n";
>
>Apache/CGI:
>
>I'm about to die() ... Content-type: text/html
>Software error:
>I'm dead.
>For help, please send mail to the webmaster ([EMAIL PROTECTED]),
>giving this error message and the time and date of
>the error.
>
>Apache/modperl:
>
>I'm about to die() ... HTTP/1.1 200 OK Date: Tue, 18 Apr 2000 11:09:35
>GMT Server: Apache/1.3.6 (Win32) mod_perl/1.22
>Connection: close Content-Type: text/html
>OK
>The server encountered an internal error or misconfiguration and was
>unable to complete your request.
>Please contact the server administrator, [EMAIL PROTECTED] and
>inform them of the time the error occurred, and
>anything you might have done that may have caused the error.
>More information about this error may be available in the server error
>log.
This should work as you expected. The reason why it did not is because of
the Perl 5.005 check. Go into your CGI::Carp.pm file and look for the
ineval() method. Manually edit it to remove the 5.005 check and just
compile an ineval() routine that is dependent on longmess() instead of $^S.
>error_syntax.pl
>---------------
>
> use CGI::Carp qw(fatalsToBrowser);
> $| = 1;
> print "Content-Type: text/html\n\n";
> print "Syntax error at the end of this line ...\n"
> print "blah blah blah.\n";
>
>Apache/CGI:
>
>Software error:
>Execution of d:/inetpub/cgi-bin/error_syntax.pl aborted due to
>compilation errors.
>For help, please send mail to the webmaster ([EMAIL PROTECTED]),
>giving this error message and the time and date of
>the error.
>
>Apache/modperl:
>
>Internal Server Error
>The server encountered an internal error or misconfiguration and was
>unable to complete your request.
>Please contact the server administrator, [EMAIL PROTECTED] and
>inform them of the time the error occurred, and
>anything you might have done that may have caused the error.
>More information about this error may be available in the server error
>log.
This you cannot solve. Although CGI::Carp can catch fatal errors at script
startup because compile errors are fatal at that point. When a stirng is
eval'ed to compile the string into a set of data, though, those errors are
NOT fatal. They are warnings.
Unfortunately, to get around this you would need to modify Apache::Registry
to trap warnings before compiling code and then die with a fatal error if
one of those warnings was a compile error.
However, to be fair, I don't think you are that concerned by this because
your scenario is the SQL runtime error scenario (just being able to
generically get the errors printed to the browser with minimal programming
overhead).
>error_divide.pl
>---------------
>
> use CGI::Carp qw(fatalsToBrowser);
> $| = 1;
> print "Content-Type: text/html\n\n";
> print "I'm about to divide by zero ...\n";
> my $x = 1 / 0;
>Apache/CGI:
>
>Software error:
>Illegal division by zero at d:/inetpub/cgi-bin/error_divide.pl line 5.
>For help, please send mail to the webmaster ([EMAIL PROTECTED]),
>giving this error message and the time and date of
>the error.
>
>Apache/modperl:
>
>Software error:
>Illegal division by zero at d:/inetpub/cgi-bin/error_divide.pl line 5.
>For help, please send mail to the webmaster ([EMAIL PROTECTED]),
>giving this error message and the time and date of
>the error.
This will not work even with the mod_perl fix because this is not a runtime
error. This particular division by zero is a compile time error-- actually
the same as your scenario 2. Perl is curiously smart enough to know that
> my $x = 1 / 0;
Is a division by zero literal error. I suppose Perl tries to take 1 / 0 as
literals and interpret them at compile time since they are constants
... Actually evaluating the expression at compile time would produce a
compile time speed up...
If you want this to be a runtime error you need to change it something like
this.
> my $zero = 0;
> my $x = 1 / $zero;
If you use this case, perl cannot optimize at compile time and will
interpret this at runtime. This runtime fatal error will be caught by
CGI::Carp (provided you fix the 5.005 thing).
Hope this helps your situation.
Later,
Gunther
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
