Programming Python (9 page)

CGI scripting in
Python is easy as long as you already have a handle on
things like HTML forms, URLs, and the client/server model of the Web
(all topics we’ll address in detail later in this book). Whether you’re
aware of all the underlying details or not, the basic interaction model
is probably familiar.

In a nutshell, a user visits a website and receives a form, coded
in HTML, to be filled out in his or her browser. After submitting the
form, a script, identified within either the form or the address used to
contact the server, is run on the server and produces another HTML page
as a reply. Along the way, data typically passes through three programs:
from the client browser, to the web server, to the CGI script, and back
again to the browser. This is a natural model for the database access
interaction we’re
after—
users can
submit a database key to the server and receive the corresponding record
as a reply page.

We’ll go into CGI basics in depth later in this book, but as a
first example, let’s start out with a simple interactive example that
requests and then echoes back a user’s name in a web browser. The first
page in this interaction is just an input form produced by the HTML file
shown in
Example 1-30
. This HTML
file is stored on the web server machine, and it is transferred to the
web browser running on the client machine upon request.

Enter your name:




        	
			  
        	

Notice how this HTML form names the script that will process its
input on the server in its
action
attribute. This page is requested by submitting its URL (web address).
When received by the web browser on the client, the input form that this
code produces is shown in
Figure 1-10
(in Internet Explorer here).

Figure 1-10. cgi101.html input form page

When this input form is submitted, a web server intercepts the
request (more on the web server in a moment) and runs the Python CGI
script in
Example 1-31
. Like the
HTML file, this Python script resides on the same machine as the web
server; it’s run on the server machine to handle the inputs and generate
a reply to the browser on the client. It uses the
cgi
module to parse the form’s input and
insert it into the HTML reply stream, properly escaped. The
cgi
module gives us a dictionary-like
interface to form inputs sent by the browser, and the HTML code that
this script prints winds up rendering the next page on the client’s
browser. In the CGI world, the standard output stream is connected to
the client through a socket.

#!/usr/bin/python
import cgi
form = cgi.FieldStorage()                 # parse form data
print('Content-type: text/html\n')        # hdr plus blank line
print('')        # html reply page
if not 'user' in form:
print('Who are you?')
else:
print('Hello %s!' % cgi.escape(form['user'].value))

And if all goes well, we receive the reply page shown in
Figure 1-11
—essentially, just
an echo of the data we entered in the input page. The page in this
figure is produced by the HTML printed by the Python CGI script running
on the server. Along the way, the user’s name was transferred from a
client to a server and back again—potentially across networks and miles.
This isn’t much of a website, of course, but the basic principles here
apply, whether you’re just echoing inputs or doing full-blown
e-whatever.

Figure 1-11. cgi101.py script reply page for input form

If you have trouble getting this interaction to run on Unix-like
systems, you may need to modify the path to your Python in the
#!
line at the top of the script file and make
it executable with a
chmod
command, but
this is dependent on your web server (again, more on the missing server
piece in a moment).

Also note that the CGI script in
Example 1-31
isn’t printing complete
HTML: the

and

tags of the static HTML file in
Example 1-30
are missing.
Strictly speaking, such tags should be printed, but web browsers don’t
mind the omissions, and this book’s goal is not to teach legalistic
HTML; see other resources for more on HTML.

Of course, to run
CGI scripts at all, we need a web server that will serve
up our HTML and launch our Python scripts on request. The server is a
required mediator between the browser and the CGI script. If you don’t
have an account on a machine that has such a server available, you’ll
want to run one of your own. We could configure and run a full
production-level web server such as the open source Apache system
(which, by the way, can be tailored with Python-specific support by the
mod_python
extension). For this
chapter, however, I instead wrote a simple web server in Python using
the code in
Example 1-32
.

We’ll revisit the tools used in this example later in this book.
In short, because Python provides precoded support for various types of
network servers, we can build a
CGI-capable
and portable HTTP web server
in just 8 lines of code (and a whopping 16 if we include comments and
blank lines).

As we’ll see later in this book, it’s also easy to build
proprietary network servers with low-level socket calls in Python, but
the standard library provides canned implementations for many common
server types, web based or otherwise. The
socketserver
module,
for instance, supports threaded and forking versions of
TCP and UDP servers. Third-party systems such as Twisted provide even
more implementations. For serving up web content, the standard library
modules used in
Example 1-32
provide what
we need
.

"""
Implement an HTTP web server in Python that knows how to run server-side
CGI scripts coded in Python;  serves files and scripts from current working
dir;  Python scripts must be stored in webdir\cgi-bin or webdir\htbin;
"""
import os, sys
from http.server import HTTPServer, CGIHTTPRequestHandler
webdir = '.'   # where your html files and cgi-bin script directory live
port   = 80    # default http://localhost/, else use http://localhost:xxxx/
os.chdir(webdir)                                       # run in HTML root dir
srvraddr = ("", port)                                  # my hostname, portnumber
srvrobj  = HTTPServer(srvraddr, CGIHTTPRequestHandler)
srvrobj.serve_forever()                                # run as perpetual daemon

The classes this script uses assume that the HTML files to be
served up reside in the current working directory and that the CGI
scripts to be run live in a
cgi-bin
or
htbin
subdirectory there. We’re using a
cgi-bin
subdirectory for scripts, as suggested by
the filename of
Example 1-31
.
Some web servers look at filename extensions to detect CGI scripts; our
script uses this subdirectory-based scheme instead.

To launch the server, simply run this script (in a console window,
by an icon click, or otherwise); it runs perpetually, waiting for
requests to be submitted from browsers and other clients. The server
listens for requests on the machine on which it runs and on the standard
HTTP port number 80. To use this script to serve up other websites,
either launch it from the directory that contains your HTML files and a
cgi-bin
subdirectory that contains your CGI
scripts, or change its
webdir
variable to reflect the site’s root directory (it will automatically
change to that directory and serve files located there).

But where in cyberspace do you actually run the server script? If
you look closely enough, you’ll notice that the server name in the
addresses of the prior section’s examples (near the top right of the
browser after the
http://
) is always
localhost
. To keep this simple, I am running the
web server on the same machine as the web browser; that’s what the
server name “localhost” (and the equivalent IP address “127.0.0.1”)
means. That is, the client and server machines are the same: the client
(web browser) and server (web server) are just different processes
running at the same time on the same computer.

Though not meant for enterprise-level work, this turns out to be a
great way to test CGI scripts—you can develop them on the same machine
without having to transfer code back to a remote server machine after
each change. Simply run this script from the directory that contains
both your HTML files and a
cgi-bin
subdirectory for
scripts and then use
http://localhost/
…
in your
browser to access your HTML and script files. Here is the trace output
the web server script produces in a Windows console window that is
running on the same machine as the web browser and launched from the
directory where the HTML files reside:

...\PP4E\Preview>
python webserver.py
mark-VAIO - - [28/Jan/2010 18:34:01] "GET /cgi101.html HTTP/1.1" 200 -
mark-VAIO - - [28/Jan/2010 18:34:12] "POST /cgi-bin/cgi101.py HTTP/1.1" 200 -
mark-VAIO - - [28/Jan/2010 18:34:12] command: C:\Python31\python.exe -u C:\Users
\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\Preview\cgi-bin\cgi101.py ""
mark-VAIO - - [28/Jan/2010 18:34:13] CGI script exited OK
mark-VAIO - - [28/Jan/2010 18:35:25] "GET /cgi-bin/cgi101.py?user=Sue+Smith HTTP
/1.1" 200 -
mark-VAIO - - [28/Jan/2010 18:35:25] command: C:\Python31\python.exe -u C:\Users
\mark\Stuff\Books\4E\PP4E\dev\Examples\PP4E\Preview\cgi-bin\cgi101.py
mark-VAIO - - [28/Jan/2010 18:35:26] CGI script exited OK

One pragmatic note here: you may need administrator privileges in
order to run a server on the script’s default port 80 on some platforms:
either find out how to run this way or try running on a different port.
To run this server on a different port, change the port number in the
script and name it explicitly in the URL (e.g.,
http://localhost:8888/
). We’ll learn more about
this convention later in this book.

And to run this server on a remote computer, upload the HTML files
and CGI scripts subdirectory to the remote computer, launch the server
script on that machine, and replace “localhost” in the URLs with the
domain name or IP address of your server machine (e.g.,
http://www.myserver.com/
). When running the server
remotely, all the interaction will be as shown here, but inputs and
replies will be automatically shipped across network connections, not
routed between programs running on the same
computer
.

To delve further into the server classes our web server script
employs, see their implementation in Python’s standard library
(
C:\Python31\Lib
for Python 3.1);
one of the major advantages of open source system like Python is that we
can always look under the hood this way. In
Chapter 15
, we’ll expand
Example 1-32
to allow the directory
name and port numbers to be passed in on the command
line.