You might find this link useful...
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Exception_Handling_for_mod_perl
Basically, fatalsToBrowser is "OK" to use, but it can be fraught with
underlying issues that Matt outlines pretty well in the above URL. Has
also given a talk on the subject at the last couple of O'Reilly conferences.
As an aside, at eXtropia, therer was a period of a couple years where we
used fatalsToBrowser quite a bit. And everytime some incompatibility
happened with mod_perl or some other advanced environment, we'd submit
the bug (and sometimes a sample patch) to Lincoln Stein who has been
very helpful.
However, Perl 5.6.0 in particular ruined all of that for us by changing
the behavior of how fatalsToBrowser worked making eval {} tests
impossible to use in your code. 5.6.1 fixed the problem, but there are
MANY ISPs still running 5.6.0 and our support email volume skyrocketted.
So now when we give out scripts we provide a "debug" version of the CGI
which calls the original CGI behind the scenes wrapped in an eval system
that can do the same thing as fatals To Browser. When you are done
"debugging", the intention is that you disable it by changing $DEBUG = 0
instead of $DEBUG = 1 or you delete the debug script off your directory.
Generally, you shouldn't enable fatalsToBrowser in production as a
general security practice.
The nice thing about making the debug into a separate script that calls
the original CGI is that if you want to re-enable debugging output in
production, your production users pointing to the main CGI script will
not get any additional information. But you can still troubleshoot with
the "debug" version of the URL which your production users won't have
(unless they've been hacking around).
This is similar in concept to the fact that CGIWRAP has a debug and
nondebug version I think. Or at least that's the inspiration for me to
have written this. If you want this "debug" wrapper program, you can get
it by downloading just about any app off our website such as "address
book". If you download "address book", you will see "address_book.cgi
and address_book_debug.cgi". The debug one can be easily modified to
work with your CGI script and as far as I know has no weird Perl version
problems like fatalsToBrowser.
Later,
Gunther
Connie Chan wrote:
>Thanks everybody, I've made it =))
>
><code>
>package Die4CGI;
>use strict;
>
>$main::SIG{__DIE__} = \&Die4CGI::die;
>
>sub die
>{ my $dieMesg = shift; $dieMesg =~ s/ at .+$//;
> my ($package, $file, $line) = caller;
> $file =~ s/^C:\\Server\\Staff\\Connie\\Project\\onTry\\/\\/;
> $file =~ s/\\/\//g;
> print "Content-type: text/html\n\n";
> print <<" HTML";
> # A lot of html #
> Garfield said: $dieMesg happens at: $file line $line.<br>
> # A lot of html #
> HTML
> ; exit(0);
>}
>
>1;
></code>
>
>So I can call it like the normal :
>
>use strict;
>use Die4CGI;
>
>my $file = 'somewhere/somewhere';
>open FH, $file or die "$!"; # prints what I want
>
>Another fatalsToBrowser, simple and lovely!! ;)
>
>*BUT!! I still not understand, how can this overided
>the orgional "die" ? Why shouldn't I write as :
>open FH, $file or Die4CGI::die($!) ;
>
>Would anybody tell me more ?
>
>Rgds,
>Connie
>
>
>
>
>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
