| |
|
|
| |
FAQ: Answers/solutions to CGI related issues...
-
What is a CGI?
CGI, or Common Gateway Interface, allows interaction between a visitor and your website.
A CGI application is a program made in a programming language (usually Perl or C) made to do just about
anything its programmer intends it to. It could be a search engine, a shopping cart, a counter,
a game, a message board, etc. There are thousands of CGI applications on the Internet,
many available for free. We recommend you take a look around and add a few CGIs to your website
to improve interactivity. It can definetely improve a visitor's experience to your website.
You may want to check the best source for CGIs (and documentation) on the Internet
is CGI-Resources.com.
-
Perl or C/C++?
Many people ask whether they should choose a CGI application made in Perl or C/C++.
The answer to that is mostly performance. Perl is an interpreted language. For a Perl
CGI to execute, the Perl interpreter must read, interpretate the program and execute it. This process
is slower, although the difference is not noticeable on Lowcountry Hosting's fast servers. It only takes less
than a second (or a second or two, depending on how complex the CGI program is) to execute the CGI
application. A program made in C/C++ is faster. This is because C/C++ is not interpretated by another
program before execution (like Perl does), it executes by itself. And since it is a "compiled" program
(that is, the CGI application was converted to low-level computer code), it can "talk" faster
to the server's CPU and operating system.
If, your CGI application will be executed only a few times per minute (like a message board),
then Perl is ok (besides, all our servers have more than 900Mhz worth of CPU power available).
If it is a CGI that will be executed too much and will do too much processing (like
an ad server on a website delivering hundreds of thousands of impressions a day), go for a C/C++ version.
Don't use Perl in that case.
There are methods to accelerate Perl scripts to a point in which they can reach the same level of
performance as a compiled script. Check our support section for more information on this.
-
Where do I put my CGI applications?
CGI scripts can be executed on any directory of your account (if your account includes CGI execution capabilities).
However, it is safer to put your CGI scripts on the /cgi-bin/ directory, since no one can read files from there through
the web. This is good specially if your scripts have files containing confidential information, such as usernames and passwords.
-
How do I make my CGI executable?
A CGI needs to be made executable before it can be used by a website/webserver.
On your account's shell (by using telnet), apply the command "chmod 755 cgi_name",
where cgi_name is the name of the CGI program file. You can also do this if you are
using an FTP program like CuteFTP by just right-clicking on the filename.
-
CHMOD? What's that?
CHMOD is a UNIX-like command used to assign permissions to a file or directory.
You can set read/write/execute permissions to a file so that you/your group/everyone
can either read, write into the file or execute it. CHMOD 755 allows everyone to
execute a file, read it, but not to write (or delete) to it. CHMOD 751 allows the same as before,
but no one can read it but you. Your account directory and all sub-directories created
with your account are set to 751 type permission. We suggest you apply this permission
to every directory you create so that no other user on the same server as your account
can read the contents of your directories.
-
500 Internal server error???
So, what happens when a good CGI goes bad? You will see a "500: Internal Server Error"
on your browser when you try to access your CGI. Contrary to what the message says,
it is not a server error. It is a script error, and figuring out why is it happening
can be quite annoying.
If your CGI application is coded in Perl, you can use the Perl interpreter to tell
you what's wrong. On your account's shell, go to the directory where the
CGI program is and just enter "perl cgi_name", where
cgi_name is the name of the CGI. If there is an error, the perl interpreter will
let you know. Also, make sure that you upload a perl script in ASCII mode. If you
don't, the script will not work.
If your CGI application is coded in C/C++, make sure its permissions were set to
executable (see above). Also, make sure it was compiled correctly.
Lowcountry Hosting's webserver has SuEXEC installed. This module allows your CGIs
to run with your ownership (not the webserver's ownership), which means that you
DO NOT need to make directories with permission 777 to have your CGI write/read files on the server.
In fact, if you have a directory with permission 777, the CGI will not work and will report
an "Internal Server Error". But, the CGI *does* need executable permissions, like
755.
Another common mistake that can cause error 500 is doing a "print" command
before sending text/html headers to the browser. You can send the headers with a
command like:
print "Content-type: text/html\n\n";
Also, CGIs will not work if you try to execute them on a subaccount (mysite.com/subaccount).
But, they will work if you assign a subdomain to the subaccount (subaccount.mysite.com).
If none of that seems to work, contact the author of the CGI application. If you think the error
in on our service, let us know and we'll investigate it.
-
Where is sendmail and perl?
Some CGIs might require the location of these two applications. The paths to both are:
/usr/sbin/sendmail
/usr/bin/perl
-
What is my site's directory path?
Your website's path is usually of the form:
/home/users/m/mysite.com/
Check the original "welcome" email we sent you when you opened your account with Lowcountry Hosting. The path is specified there.
-
I'm having problems installing a Perl script...
Perl scripts can cause many types of errors if they are not set correctly. Things to usually check for are:
- Is the path to Perl correct at the beginning of the script?
- Is the script's permission set to executable?
- Is the actual syntax in the script correct?
One thing you can do is log in to your account's shell, and execute your script with the Perl interpreter like this:
perl -we my_script.pl
Perl will then list all errors found on the script. Also, if you execute the script in the following way:
./my_script.pl
and the shell responds with a "file not found" message, it means the script's path to Perl is wrong, or the
script was uploaded in binary mode and not ASCII mode.
-
My CGI script won't work when called through SSI...
First, to call a CGI through SSI, your page must have either an .shtml or .shtm extension.
Then, to execute a CGI from the page, it must be called in the following way:
<!--#exec cgi="cgi-bin/my_script.cgi"-->
We suggest you first try the CGI by executing it directly through the browser (www.yoursite.com/cgi-bin/my_script.cgi)
to make sure it is working.
-
How can I accelerate my Perl scripts?
Everytime a CGI coded in Perl is executed on your website, the server has to launch the Perl interpreter,
the Perl interpreter will then analyze the script's syntax, it will then compile the script and then execute it.
Although all of this happens in less than a second, it puts too much load on a server, specially if the script
is being excuted repeatedly.
A solution for this is using a method that will allow the compiled script to remain in memory, waiting to be executed.
This way, the overhead of launching the Perl interpreter is eliminated.
One way of doing this is by using Speedy. You can use Speedy by replacing the following line in your Perl scripts:
#!/usr/bin/perl
for
#!/usr/bin/speedy -- -t300
Now, the first time the script is executed, Speedy will launch the Perl interpreter to analyze the code and compile it.
Speedy will then take the compiled version, keep it in memory and execute it. The next time the same script is called,
Speedy will just execute it. No need for the Perl interpreter to be relaunched.
The "-- -t300" parameter tells Speedy to keep the script in memory for 300 seconds after every execution.
If 300 seconds go by without the script being executed, it is then removed from memory. We suggest you do not raise this
parameter.
If your script is rarely executed (like once every 10 minutes or longer), then just use Perl as usual and not Speedy.
NOTE: values for variables will remain in memory! Your script should undefine these variables when execution is finished.
In fact, Speedy doesn't tolerate errors on your scripts, even warnings. So, before using Speedy, execute your script
on your account's shell like this:
perl -wc my_script.pl
Perl will then list all errors and warnings on your script. You must fix them before using Speedy.
|
|
| |
|
|
|
_
_
_
