Blank screen or 403 from Perl script

Struggling to get started in cgi and Perl

[kiwibrit]

I use PHP, so I am unfamiliar with Perl, but I thought I would have a go to get myself familiar with using cgi.

From CGI101.com I came across this script

#!/usr/bin/perl -wT
print "Content-type: text/html\n\n";
print "Hello, world!\n";

I wrote the script in Notepad, and FTPd it to mysite.com/first.cgi and gave it chmod 755.

From my web host control panel:

Path to Perl: /usr/bin/perl
Perl modules: All standard Perl modules, including DBI, are installed.
Perl version: 5.8.5 (patched)

In FF2 I get a blank screen - and in IE7 I get a 403. What's gone wrong?

[kiwibrit]

Dropping the script into cgi-bin cracked it - but I am puzzled why the web host server was configured not to run a script outside the cgi-bin. Any ideas on that?

[Xelion]

Its usually an issue of security.

[phranque]

the cgi-bin restriction is like an electronic dog fence.
you can only get bit if you are inside the fence...

[zCat]

I think it's just a tradition from the days when Web 1.0 was in early beta.

You can, after all, put a PHP file anywhere and it will be executed. Unfortunately for Perl it never grew out of the /cgi-bin directory into an easily usable form like PHP, which is why it's pretty much lost its way as a web language.

[phranque]

wow - nice troll!
i've actually never run one of my perl cgi scripts from the cgi-bin directory, so that shows what a small bit of knowledge can do for you.
as far as php is concerned, it is so easy to use that i spend more time answering questions in the php forum than here - and i've never written a word of php.

a hammer is easy to use - so what?

[perl_diver]

any host that restricts cgi scripts (no matter what language they are written in) to the cgi-bin simply does not know how to setup the server or thinks that is what customers have come to expect and they are confused when there is no cgi-bin directory, because most cgi scripts say to upload the script into the cgi-bin because they think the server will be setup like that, it's a bit of a vicious circle.

In reality, any folder with it's permission bits set to execute should run scripts as safely as any script that is in a cgi-bin folder. The cgi-bin generally has directory browsing turned off by defualt and will only try and run scripts/programs instead of just returning them like an html document or image.

The advantage to this is an organized repository of all your cgi scripts that the outside world can't get a listing of and you can store data in the cgi-bin and it is relatively safe from http access since direct access to it will result in a server error. The other advantage is that it is setup in the server directives, making it faster and safer than using .htaccess files on a per folder basis.

But all this can be done in any folder by anyone that understands some basic server setup stuff, so the cgi-bin is merely a convenience for the casual user that does not know how to setup scripts and data files in a secure way themselves.

[zCat]

wow - nice troll!
i've actually never run one of my perl cgi scripts from the cgi-bin directory, so that shows what a small bit of knowledge can do for you.
as far as php is concerned, it is so easy to use that i spend more time answering questions in the php forum than here - and i've never written a word of php.

a hammer is easy to use - so what?

Was that aimed at my comment? If so, I hasten to point out that I do most of my programming in Perl, more precisely mod_perl. My comment was meant to reflect the sad fact that virtually all the hosting providers I've come across do the standard /cgi-bin setup...

[edited by: zCat at 6:01 pm (utc) on Aug. 15, 2007]

[phranque]

sorry zcat - perhaps i misunderstood your point.
i don't have much experience with perl applications on standard "hosting providers" as we do our own hosting and configure as necessary.
sometimes with mod_perl...
=8)