The browser will hang until it times out. It is waiting for your script to output a header. At the command line I very much doubt that there is a 30 second delay between calling exit and the program exiting with a return of the prompt although it could be executing a long END{ } block. Do you have a line like "$|++;print 'exiting...\n';exit;" that demonstrates this delay?

I use this die_nice function a bit:

sub die_nice {
    my $real_error = shift;
    email($administrator, $real_error);
    log_error(scalar localtime, $real_error);
    tell_user('Sorry the system can not respond to your request due to
+ routine maintenance
              <br>Please try again later')  # yeah, right!
  exit;
}

sub tell_user {
    print "Content-type: text/html\n\n<p>" . shift;
}
[download]

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Nice definition of 'routine' you have there :)

use CGI::Carp qw(fatalsToBrowser);
[download]

See also this thread

While 'fatalsToBrowser' is great for debugging it should be commented out for production IMHO. The reasons are 1) that it reveals far too much detail to someone who is deliberately hacking your system and 2) does not produce a particularly user friendly message (better than a 500 but not much). I think a die_nice routine (as noted above) is better idea as it lets you kid the user everything is OK while silently logging the problem and/or sending you an email to fix it.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

I disagree to this blanket statement. We use fatalsToBrowser (with a custom message), but we're just very particular about where we let the program die. I can list off all of the die calls for our entire application off the top of my head -- and they're all severe enough to warrant something evil. Die() is reserved for Should Never Happen errors.

So if *we* didn't call die, then Perl must have bailed. Modules I have wrapped in eval {} because I don't want them dying -- ever. (XML::Parser--) This pretty much just leaves compilation errors and if we've put a program onto production that won't compile then we've got much more serious issues than the user seeing an ugly message.

exit does not stop the compilation of your script. It stops the execution of your already compiled script.

The browser is waiting for an HTML page as a result of the HTML page request it sent to the HTML server.

Your script is supposed to always return a valid HTML page to the browser, hopefully containing valid information but if necessary containing general information about the type of error detected and indicating what the user should do.

The page should not contain Perl related data dumps, variable names, etc. since this could potentially give an evil visitor a hint of how to deliberately break your script.