What is a CGI script?
A CGI script is a program created by you that allows you to generate dynamic web pages, ie pages that may look different each time they are opened. The content may depend on the current time, the content of the various files, the address of the computer from which the page is visited, etc.
How to create a CGI script
A CGI script is any (server-side) executable file (usually a script - hence the name) that, when run on standard output, prints the HTTP header of the page (not to be confused with the HTML header) and then its own content . It can be classic text in HTML, but also any other type of data.
The script should generate at least a header
Content-Type: followed by a blank line indicating the end of the header. An example of a simple CGI script written in a shell
#!/bin/bash echo "Content-Type: text/html" echo echo "<body>" echo "my first example page \o/" echo "<pre>" date echo "</pre>" echo "</body>"
/bin/bash is the full path to the interpreter to run the script on the server. It can be Bash, Perl, PHP or something else. However, be careful if you write your pages and scripts in editors or on systems where the character is stored at the end of lines.
CR (Ctrl-M, ^ M) - typically windows programs. Then a program would not be sought
bash in the directory
/bin but some kind of program
bash^M which, of course, does not exist.
Content-Type: is in this case
text/html , which means for the WWW server that the CGI script generates an HTML page. If the script generated, for example, an image,
Content-Type would be, say,
The CGI script must be executable on Aise. In order for the WWW server to recognize that it is a CGI script, the script must have a .cgi extension.
Custom CGI scripts available under / ~ xlogin /
The CGI script must be executable by the owner, which you can do with the command:
chmod u+x ~/public_html/script.cgi
If it is not a binary program, but really a script, you also need to set the read right by the owner.
Scripts are run using a mechanism
suexec which allows the script to be executed under the identity of the owner. It also checks some security conditions. The basis is: the script must belong to the user specified in the URL (
xlogin/ ) and the group that this user has as primary (can be found by the command
id ). Neither the script nor the parent directory must be write-enabled for the group and others.
CGI scripts stored outside the tree / ~ xlogin /
These CGI scripts must be executable (permissions
x ) by apachefi; if it is not a binary program, but a script, it is necessary to have the right to read (
r ) by apaechefi. This can be achieved by a command
setfacl -m u:apachefi:r-x script.cgi . Running CGI scripts run under a user identity
apachefi , and it is therefore necessary to adapt the behavior of the script accordingly. Typically, for example, this user can only write to the directory
Special variables in CGI scripts, working with parameters in URLs
The web server sets several new variables that you can work with in the CGI script. You can find out which ones they are by following the example given in
section on debugging CGI scripts . Especially if you pass parameters to a CGI script (GET method), they will be available in the variable
QUERY_STRING . In a shell CGI script, the processing of parameters may look like this:
#!/bin/bash . /packages/run.64/bashlib-0.4/bin echo Content-type: text/plain echo HOST=$(param host) /usr/bin/host $HOST
This program stores it in a variable
HOST parameter value
host . Therefore, if you call the program using a URL
xlogin/this_script.cgi?host=aisa , its output will be the output of the command
host aisa . (More on bashlib at
If you pass parameters by method
POST , the data is passed to the standard input of the CGI script.
CGI scripts and security
It is important to note that if a running CGI script is invoked in a subtree
runs under your identity . Therefore, if you make a security error in the script, your data on the server may be lost / changed or your identity may be misused. Therefore, always check the script carefully before publishing it and take into account that someone may try to test the robustness and resilience of your script manually. This applies in particular to parameter processing.
Also keep in mind that the examples on this page are for illustrative purposes only (although not functional) and may not be written securely. Before you start writing CGI scripts, we recommend that you read something about this issue on the web.
Debugging CGI scriptsWe recommend that you first try to run the CGI script from the command line directly on Aise. Here you can catch, for example, artist error messages. It is very likely that after running under the user
apachefithe script will not have some environment variables set (typically
LD_LIBRARY_PATH, ...). For example, the following code can find out the current state of variables when running a CGI script:
#!/bin/bash echo "Content-type: text/plain" echo set
Debugging Perl scripts:
use CGI, which allows you to debug scripts on the command line, including parameters.
use CGI::Carp qw(fatalsToBrowser), which displays error messages to the browser.
Debugging shell scripts:
- Right after the opening
#!/bin/bash) add a line
exec 2>/home/ xlogin/public_html/stderr.logwhich redirects error output to a file.
- If you use modules, you need to initialize them first. See page for more details modules .
- Please read this page again.
- Double check that you have the correct access rights on the directory
~/public_htmland nested (for details see page about custom HTML pages .
- Double check that the CGI script has an extension
- Recheck the access rights to the CGI script and its relevant environment.
- Again, try to run the CGI script manually on Aise from the command line.
- If the script works on the command line, but not when accessed through the Web, look in the Web server logs for a possible cause. Where are the logs stored?
- Consult with more experienced colleagues.
- Consult the administrator.