}''.
\end{funcdesc}
\subsection{Caring about security}
There's one important rule: if you invoke an external program (e.g.
via the \code{os.system()} or \code{os.popen()} functions), make very sure you don't
pass arbitrary strings received from the client to the shell. This is
a well-known security hole whereby clever hackers anywhere on the web
can exploit a gullible CGI script to invoke arbitrary shell commands.
Even parts of the URL or field names cannot be trusted, since the
request doesn't have to come from your form!
To be on the safe side, if you must pass a string gotten from a form
to a shell command, you should make sure the string contains only
alphanumeric characters, dashes, underscores, and periods.
\subsection{Installing your CGI script on a Unix system}
Read the documentation for your HTTP server and check with your local
system administrator to find the directory where CGI scripts should be
installed; usually this is in a directory \code{cgi-bin} in the server tree.
Make sure that your script is readable and executable by ``others''; the
Unix file mode should be 755 (use \code{chmod 755 filename}). Make sure
that the first line of the script contains \code{\#!} starting in column 1
followed by the pathname of the Python interpreter, for instance:
\bcode\begin{verbatim}
#!/usr/local/bin/python
\end{verbatim}\ecode
%
Make sure the Python interpreter exists and is executable by ``others''.
Make sure that any files your script needs to read or write are
readable or writable, respectively, by ``others'' -- their mode should
be 644 for readable and 666 for writable. This is because, for
security reasons, the HTTP server executes your script as user
``nobody'', without any special privileges. It can only read (write,
execute) files that everybody can read (write, execute). The current
directory at execution time is also different (it is usually the
server's cgi-bin directory) and the set of environment variables is
also different from what you get at login. in particular, don't count
on the shell's search path for executables (\code{\$PATH}) or the Python
module search path (\code{\$PYTHONPATH}) to be set to anything interesting.
If you need to load modules from a directory which is not on Python's
default module search path, you can change the path in your script,
before importing other modules, e.g.:
\bcode\begin{verbatim}
import sys
sys.path.insert(0, "/usr/home/joe/lib/python")
sys.path.insert(0, "/usr/local/lib/python")
\end{verbatim}\ecode
%
(This way, the directory inserted last will be searched first!)
Instructions for non-Unix systems will vary; check your HTTP server's
documentation (it will usually have a section on CGI scripts).
\subsection{Testing your CGI script}
Unfortunately, a CGI script will generally not run when you try it
from the command line, and a script that works perfectly from the
command line may fail mysteriously when run from the server. There's
one reason why you should still test your script from the command
line: if it contains a syntax error, the python interpreter won't
execute it at all, and the HTTP server will most likely send a cryptic
error to the client.
Assuming your script has no syntax errors, yet it does not work, you
have no choice but to read the next section:
\subsection{Debugging CGI scripts}
First of all, check for trivial installation errors -- reading the
section above on installing your CGI script carefully can save you a
lot of time. If you wonder whether you have understood the
installation procedure correctly, try installing a copy of this module
file (\code{cgi.py}) as a CGI script. When invoked as a script, the file
will dump its environment and the contents of the form in HTML form.
Give it the right mode etc, and send it a request. If it's installed
in the standard \code{cgi-bin} directory, it should be possible to send it a
request by entering a URL into your browser of the form:
\bcode\begin{verbatim}
http://yourhostname/cgi-bin/cgi.py?name=Joe+Blow&addr=At+Home
\end{verbatim}\ecode
%
If this gives an error of type 404, the server cannot find the script
-- perhaps you need to install it in a different directory. If it
gives another error (e.g. 500), there's an installation problem that
you should fix before trying to go any further. If you get a nicely
formatted listing of the environment and form content (in this
example, the fields should be listed as ``addr'' with value ``At Home''
and ``name'' with value ``Joe Blow''), the \code{cgi.py} script has been
installed correctly. If you follow the same procedure for your own
script, you should now be able to debug it.
The next step could be to call the \code{cgi} module's test() function from
your script: replace its main code with the single statement
\bcode\begin{verbatim}
cgi.test()
\end{verbatim}\ecode
%
This should produce the same results as those gotten from installing
the \code{cgi.py} file itself.
When an ordinary Python script raises an unhandled exception
(e.g. because of a typo in a module name, a file that can't be opened,
etc.), the Python interpreter prints a nice traceback and exits.
While the Python interpreter will still do this when your CGI script
raises an exception, most likely the traceback will end up in one of
the HTTP server's log file, or be discarded altogether.
Fortunately, once you have managed to get your script to execute
*some* code, it is easy to catch exceptions and cause a traceback to
be printed. The \code{test()} function below in this module is an example.
Here are the rules:
\begin{enumerate}
\item Import the traceback module (before entering the
try-except!)
\item Make sure you finish printing the headers and the blank
line early
\item Assign \code{sys.stderr} to \code{sys.stdout}
\item Wrap all remaining code in a try-except statement
\item In the except clause, call \code{traceback.print_exc()}
\end{enumerate}
For example:
\bcode\begin{verbatim}
import sys
import traceback
print "Content-type: text/html"
print
sys.stderr = sys.stdout
try:
...your code here...
except:
print "\n\n"
traceback.print_exc()
\end{verbatim}\ecode
%
Notes: The assignment to \code{sys.stderr} is needed because the traceback
prints to \code{sys.stderr}.
The \code{print "{\e}n{\e}n"} statement is necessary to
disable the word wrapping in HTML.
If you suspect that there may be a problem in importing the traceback
module, you can use an even more robust approach (which only uses
built-in modules):
\bcode\begin{verbatim}
import sys
sys.stderr = sys.stdout
print "Content-type: text/plain"
print
...your code here...
\end{verbatim}\ecode
%
This relies on the Python interpreter to print the traceback. The
content type of the output is set to plain text, which disables all
HTML processing. If your script works, the raw HTML will be displayed
by your client. If it raises an exception, most likely after the
first two lines have been printed, a traceback will be displayed.
Because no HTML interpretation is going on, the traceback will
readable.
\subsection{Common problems and solutions}
\begin{itemize}
\item Most HTTP servers buffer the output from CGI scripts until the
script is completed. This means that it is not possible to display a
progress report on the client's display while the script is running.
\item Check the installation instructions above.
\item Check the HTTP server's log files. (\code{tail -f logfile} in a separate
window may be useful!)
\item Always check a script for syntax errors first, by doing something
like \code{python script.py}.
\item When using any of the debugging techniques, don't forget to add
\code{import sys} to the top of the script.
\item When invoking external programs, make sure they can be found.
Usually, this means using absolute path names -- \code{\$PATH} is usually not
set to a very useful value in a CGI script.
\item When reading or writing external files, make sure they can be read
or written by every user on the system.
\item Don't try to give a CGI script a set-uid mode. This doesn't work on
most systems, and is a security liability as well.
\end{itemize}