Oft times you'll invoke a CGI script, and while the script will in fact execute, it doesn't quite do what you were expecting. Ascertaining the nature of the problem can prove spectacularly frustrating when you have as many degrees of separation as you do in the scenario of invoking the script indirectly via a web browser. You type something into your browser, it sends a request to the server, the server invokes the script, takes back its output, and sends it back to the browser. There may even be additional intermediary steps that obscure the problem.

Being able to cut both the web browser and web server out of the picture, thus isolating the script, can be quite useful. This will enable you to see the pure, raw output of your script, including the HTTP headers, as well as give you all of the output of your script, even in the event of a crash... far more useful than just seeing "INTERNAL SERVER ERROR" and only being able to ascertain the direct cause of the script crash, as opposed to seeing all output that preceded the crash. Of course, to get the full picture you need to be able to send in the same form parameters that you were previously doing through the request originating from the browser.

To do this, you'll want to instantiate a CGI object with a file handle opened to a file that contains field/value pairs, or with STDIN and type in the values when you run the script.

use CGI;
open(FILE, "<data.txt") or die "gah!";
my $query = CGI->new(FILE);
...
[download]

Where data.txt contains stuff like...

foo=bar
baz=biz
[download]

This paradigm will aid in detection of the problem, potentially exposing previously hidden issues, as well as greatly expedite the run/debug/tweak cycle.