Test case mock-up
The dummy class definition, commented out in this final version, was used to debug
the script before it was installed on the Net. Besides not seeing stderr messages by
default, CGI scripts also assume an enclosing context that does not exist if they are
tested outside the CGI environment. For instance, if run from the system command
line, this script has no form input data. Uncomment this code to test from the
system command line. The dummy class masquerades as a parsed form field object,
and form is assigned a dictionary containing two form field objects. The net effect
is that form will be plug-and-play compatible with the result of a
cgi.FieldStorage call. As usual in Python, object interfaces, not datatypes, are all
we must adhere to.
Here are a few general tips for debugging your server-side CGI scripts:
Run the script from the command line
It probably won’t generate HTML as is, but running it standalone will detect any
syntax errors in your code. Recall that a Python command line can run source code
files regardless of their extension: for example, python somescript.cgi works fine.
Assign sys.stderr to sys.stdout as early as possible in your script
This will generally make the text of Python error messages and stack dumps appear
in your client browser when accessing the script, instead of the web server’s console
window or logs. Short of wading through server logs or manual exception handling,
this may be the only way to see the text of error messages after your script aborts.
Mock up inputs to simulate the enclosing CGI context
For instance, define classes that mimic the CGI inputs interface (as done with the
dummy class in this script) to view the script’s output for various test cases by running
it from the system command line.‖ Setting environment variables to mimic form
or URL inputs sometimes helps, too (we’ll see how later in this chapter).
Call utilities to display CGI context in the browser
The CGI module includes utility functions that send a formatted dump of CGI
environment variables and input values to the browser, to view in a reply page. For
instance, cgi.print_form(form) prints all the input parameters sent from the client,
and cgi.test() prints environment variables, the form, the directory, and more.
Sometimes this is enough to resolve connection or input problems. We’ll use some
of these in the webmail case study in the next chapter.
Show exceptions you catch, print tracebacks
If you catch an exception that Python raises, the Python error message won’t be
printed to stderr (that is normal behavior). In such cases, it’s up to your script to
‖This technique isn’t unique to CGI scripts, by the way. In Chapter 12, we briefly met systems that embed
Python code inside HTML, such as Python Server Pages. There is no good way to test such code outside the
context of the enclosing system without extracting the embedded Python code (perhaps by using the
html.parser HTML parser that comes with Python, covered in Chapter 19) and running it with a passed-in
mock-up of the API that it will eventually use.
1162 | Chapter 15: Server-Side Scripting