in reply to Re: mod_perl with Apache::Registry with CGI.pm design considerations
in thread mod_perl with Apache::Registry with CGI.pm design considerations

Thank you for the advice. As a rule, I use the following in my CGI:
use strict; use warnings; use diagnostics; ...
In httpd.conf, I use:
PerlTaintCheck On PerlModule Apache::DBI PerlModule Apache::StatINC ... <Files ~ "\.pl$"> SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options ExecCGI </Files>
I've been running the script under -T -d also, at the shell, looking for culprets. I've managed to cut it down into a smaller subset of functions, no graphics, no CGI.pm-driven HTML, and the problem went away. Now I have to start adding bits to see when it occurs again.

Replies are listed 'Best First'.
Re: Re: Re: mod_perl with Apache::Registry with CGI.pm design considerations
by Anonymous Monk on Nov 13, 2002 at 14:11 UTC
    Yah. you may use strict, but you're not really using it. You pre-declare all your variables up-front, like you're writing C code. Declare your variables at the last possible moment! That way, you make sure that the scoping is as tight as possible.

    Also, don't use diagnostics in a production webserver. That's extremely expensive and, almost always, completely useless. All it does is extend warnings. If you're programming enough, you know where the problem is just by seeing the brief warning text.

    A piece of advice - learn modules. If you start to break 10k lines, you really start to want them. After 20k-30k or so lines in your web application, modules become a necessity. There are simply too many places a web application can go wrong for you to have to try and trace which copy of this block of code is wrong. I've seen savings of 80% in time and 95% in lines of code maintained by (intelligently) shifting to modules. And, if you shift to an OO system, you can save up to 99% in terms of lines. (These are not exagerrations - at my prior job, those were the numbers.)