[boulder.pm] bounced e-mail from Rob
walter at frii.com
Sun Aug 19 13:55:45 CDT 2001
> I contacted my ISP last Monday, Earthnet. All my sys op did was to create
> a directory under my /public_html of cgi-bin , then move my script into
> it with a .cgi file extension. He then said "done." Well, I get a 403
> permission denied error. And on an unanswered follow up post, my sys op
> did not explain any thing regarding wrapper calls.
> What is the the proper file extension for cgi scripts? *.cgi?
> What is the proper permission?
> How do I run the cgi script? use a url file name convention? (book hinted
> Please note, I did a google search on cgi wraps and received info to mark
> the file as executable, then http://isp.com/seo-bin/chmod (wait for user
> name-password prompt.) I tried this with my isp and got a no file found
Helpful sysadmin, eh?
There is no "correct" filename extension that denotes a file to be
run as a CGI script rather than having its contents pushed out as straight
text. That said, .cgi is fairly standard. The apache server, for example,
cna be configured to either (1) treat everything in a particular directory,
no matter what its filename extension, as a CGI program, or (2) treat anything
with a particular filename extension, no matter where it's located,
as a CGI program. You need to find and read your server's config files
to figure out all the options you may have at your disposal, if the sysadmin
is being unhelpful or clueless.
Your problem sounds like one of file or directory permissions. The
CGI file *and the path to it* must be readable by the username that
the webserver is running under (typically a low-permissions account
such as 'nobody'). So if your setup is something like
but ~robmohr, public_html, or cgi-bin aren't world-readable, you'll
get that 403 Forbidden message. In Unix lingo (I don't know the
system or server software you're dealing with), those directories
would need to be drwxr-xr-x and the script -rwxr-xr-x.
How to run the CGI script.
The obvious way to run it is via the browser and a URL. But if
you're using Lincoln Steins CGI.pm module, it's also simple to run
it from the command line. If you're depending on environment variables
that get passed in with the request, this becomes more effort, and
ultimately unworkable for all practical purposes as the script gets
complicated, but it can be fun to play with when you're bored.
Basically, I include that to be a pedant; I do all my developing via
the browser. Make a change, save file, hit reload, look at the output
(or ;^) at the window where I have a tail -f of the error_log going).
It's pretty efficient.
How to debug the CGI script. As you develop, you'll get a bunch of
500 Internal Server Error messages. All that means is that your script
sent something unexpected (i.e., not valid HTTP stuff) to the server.
(1) Look in the server's error log for enlightenment, because that's
where the meaningful output is,
use CGI::Carp qw(fatalsToBrowser);
in your program. (Take it out when you're done debugging; otherwise
sensitive info can get out to the world.)
(3) If the admin is really an idiot, you may not have access to the
error log. Oops. But since the webserver does (it writes to it,
hey?), just write a CGI program that reads it!
One last comment. If you're going to play with CGI, NEVER NEVER NEVER
NEVER NEVER NEVER NEVER NEVER NEVER write a real, for-public-access script
without the -T switch to turn taint checking on. In fact, when I write one,
it ALWAYS starts like so:
CGI scripts on a public server basically have to handle arbitrary input
(not just what you expect) from bored and/or malicious people worldwide,
and the mechanisms behind -T will save you much grief.
Have fun. There are a lot of genuinely cool and fun things to be
done via CGI.
More information about the Boulder-pm