BTW, Are you using the handy

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

On my box, that prevents the 500 error, but produces a page with no displayable data.

die sends the message to STDERR, which normally goes into your server error log. Depending on what's been sent to STDOUT (the user agent), the web server may have to send error information.

If I were you, though, I'd use Carp and fatalsToBrowser during development instead of die, and work up some sort of error reporting mechanism that logs errors and reports them to users gracefully for production.

Before anything can be sent to the browser you first have to tell it what kind of data to expect. The "kind of data" (called the "MIME" type) is sent when you send the "Content-type" header, as in

print "Content-type: text/html\n\n";

# or, same thing but better
use CGI qw (:standard);

print header;
[download]

virtualsue's suggestion to use CGI::Carp qw(fatalsToBrowser); is the solution. This causes any calls to "die" to be redirected to STDOUT, with the proper content-type header, allowing you to automagically see the content of your error message. It's very cool. Use it in good health.

Gary Blackburn
Trained Killer

Correction: Corrected STDOUT to STDERR. Ooops.

I appreciate the detail you furnished. The first lines of the script are now:

#!/usr/bin/perl

use CGI qw(:standard); 

print header;

use CGI::Carp qw(fatalsToBrowser);
$query = new CGI;
etc....
[download]

I'm still getting that silly ol' Internal Server Error message.
laura.guimauve

Have you tried running it from the command line? If you are still getting a 500 error, it quite likely is due to a syntax error in your script. Whenever I tinker with one of my CGI programs I always run it quickly from the editor to see if I broke anything before trying it from a browser.

I also suggest turning on warnings and taint mode via

#!/usr/bin/perl -wT
[download]

and enabling strict syntax checking like so

use strict;
[download]

Taint mode is essential for security reasons, whereas the other things are just plain good for your development as a perl programmer. For more info on these, there is a wealth of information on this site (or just keep asking questions). You should also read 'perldoc perlsec' since you are writing CGI code.

FYI, if you use

use CGI qw (:standard);
[download]

that's using CGI.pm in "function" mode, meaning there is no need to instantiate an object to use all the nifty CGI features. This is why print header; works. The "header" function gets imported from CGI into your program by the qw(:standard) bit in "use CGI." There are plenty of docs for this in the POD for CGI.pm.

The long and the short of it is: if you're using qw(:standard) don't bother using $query=new CGI. In fact, as I have discovered on a couple of occassions, doing so can even get you into trouble. :-(

But that's probably not your problem. Whenever you get Error 500 messages it means that your web browser is not getting what it expects, which means your CGI is not providing good, properly header'd information. If you have fatalstobrowser turned on and you're still getting the error it means your program isn't even compiling properly. (If it compiled, FatalsToBrowser would kick in and tell you what was wrong.) To check compilation do a perl -c yourscript.cgi from the command line to root out any nasty syntax errors.

Gary Blackburn
Trained Killer

Can you look at the server's error log? I don't think it's the die at this point, maybe CGI::Carp isn't installed?

--isotope
http://www.skylab.org/~isotope/

that'll send your fatals to the browser window ( good for development code, prolly bad for production code. )