Read Programming Python Online

Authors: Mark Lutz

Tags: #COMPUTERS / Programming Languages / Python

Programming Python (151 page)

BOOK: Programming Python
13.75Mb size Format: txt, pdf, ePub
ads
HTML file permission constraints

One install
pointer before we move on: if you want to use a
different server and machine, it may be necessary on some platforms to
grant web page files and their directories world-readable permission.
That’s because they are loaded by arbitrary people over the Web (often
by someone named “nobody,” who we’ll introduce in a moment).

An appropriate
chmod
command
can be used to change permissions on Unix-like machines.
For instance, a
chmod 755
filename
shell command usually suffices; it
makes
filename
readable and executable by
everyone, and writable by you only.
[
58
]
These directory and file permission details are typical,
but they can vary from server to server. Be sure to find out about the
local server’s conventions if you upload HTML files to a remote
site.

A First CGI Script

The HTML file we
saw in the prior section is just that—an HTML file, not a
CGI script. When referenced by a browser, the remote web server simply
sends back the file’s text to produce a new page in the browser. To
illustrate the nature of CGI scripts, let’s recode the example as a
Python CGI program, as shown in
Example 15-3
.

Example 15-3. PP4E\Internet\Web\cgi-bin\tutor0.py

#!/usr/bin/python
"""
runs on the server, prints HTML to create a new page;
url=http://localhost/cgi-bin/tutor0.py
"""
print('Content-type: text/html\n')
print('Read Programming Python (151 page) Page 151 Read Book Online,Top Vampire Books Read Online Free')
print('

A First CGI Script

')
print('

Hello, CGI World!

')

This file,
tutor0.py
, makes the same sort of
page as
Example 15-2
if you
point your browser at it—simply replace
.html
with
.py
in the URL, and add the
cgi-bin
subdirectory name to the path to yield its
address to enter in your browser’s address field,
http://localhost/cgi-bin/tutor0.py
.

But this time it’s a very different kind of animal—it is an
executable program
that is run on the server in
response to your access request. It’s also a completely legal Python
program, in which the page’s HTML is printed dynamically, instead of
being precoded in a static file. In fact, little is CGI-specific about
this Python program; if run from the system command line, it simply
prints HTML instead of generating a browser page:

C:\...\PP4E\Internet\Web\cgi-bin>
python tutor0.py
Content-type: text/html
Read Programming Python (151 page) Page 151 Read Book Online,Top Vampire Books Read Online Free

A First CGI Script


Hello, CGI World!


When run by the HTTP server program on a web server machine,
however, the standard output stream is tied to a socket read by the
browser on the client machine. In this context, all the output is sent
across the Internet to your web browser. As such, it must be formatted
per the browser’s expectations.

In particular, when the script’s output reaches your browser, the
first printed line is interpreted as a header, describing the text that
follows. There can be more than one header line in the printed response,
but there must always be a blank line between the headers and the start
of the HTML code (or other data). As we’ll see later, “cookie” state
retention directives show up in the header area as well, prior to the
blank line.

In this script, the first header line tells the browser that the
rest of the transmission is HTML text (
text/html
),
and the newline character (
\n
) at the
end of the first
print
call statement
generates an extra line feed in addition to the one that the
print
generates itself. The net effect is to
insert a blank line after the header line. The rest of this program’s
output is standard HTML and is used by the browser to generate a web
page on a client, exactly as if the HTML lived in a static HTML file on
the server.
[
59
]

CGI scripts are accessed just like HTML files: you either type the
full URL of this script into your browser’s address field or click on
the
tutor0.py
link line in the examples root page
of
Figure 15-1
(which follows a
minimal hyperlink that resolves to the script’s full URL).
Figure 15-3
shows the result page
generated if you point your browser at this script.

Figure 15-3. A simple web page from a CGI script

Installing CGI scripts

If you are running
the local web server described at the start of this
chapter, no extra installation steps are required to make this example
work, and you can safely skip most of this section. If you want to put
CGI scripts on another server, though, there are a few pragmatic
details you may need to know about. This section provides a brief
overview of common CGI configuration details for reference.

Like HTML files, CGI scripts are simple text files that you can
either create on your local machine and upload to the server by FTP or
write with a text editor running directly on the server machine
(perhaps using a Telnet or SSH client). However, because CGI scripts
are run as programs, they have some unique installation requirements
that differ from simple HTML files. In particular, they usually must
be stored and named specially, and they must be configured as programs
that are executable by arbitrary users. Depending on your needs, CGI
scripts also may require help finding imported modules and may need to
be converted to the server platform’s text file format after being
uploaded. Let’s look at each install constraint in more depth:

Directory and filename
conventions

First, CGI scripts
need to be placed in a directory that your web
server recognizes as a program directory, and they need to be
given a name that your server recognizes as a CGI script. In the
local web server we’re using in this chapter, scripts need to be
placed in a special
cgi-bin
subdirectory
and be named with a
.py
extension. On the
server used for this book’s second edition, CGI scripts instead
were stored in the user’s
public_html
directory just like HTML files, but they required a filename
ending in a
.cgi
, not a
.py
. Some servers may allow other suffixes
and program directories; this varies widely and can sometimes be
configured per server or per user.

Execution conventions

Because they
must be executed by the web server on behalf of
arbitrary users on the Web, CGI script files may also need to be
given executable file permissions to mark them as programs and
be made executable by others. Again, a shell command
chmod 0755
filename
does the trick on most
servers.

Under some servers, CGI scripts also need the special
#!
line at the top, to
identify the Python interpreter that runs the file’s code. The
text after the
#!
in the
first line simply gives the directory path to the Python
executable on your server machine. See
Chapter 3
for more details on this
special first line, and be sure to check your server’s
conventions for more details on non-Unix platforms.

Some servers may expect this line, even outside Unix. Most
of the CGI scripts in this book include the
#!
line just in case they will ever be
run on Unix-like platforms; under our locally running web server
on Windows, this first line is simply ignored as a Python
comment.

One subtlety worth noting: as we saw earlier in the book,
the special first line in executable text files can normally
contain either a hardcoded path to the Python interpreter (e.g.,
#!/usr/bin/python
) or an invocation of the
env
program (e.g.,
#!/usr/bin/env python
), which
deduces where Python lives from environment variable settings
(i.e., your
$PATH
). The
env
trick is less useful in
CGI scripts, though, because their environment settings may be
those of the user “nobody” (not your own), as explained in the
next paragraph.

Module search path configuration
(optional)

Some HTTP
servers may run CGI scripts with the username
“nobody” for security reasons (this limits the user’s access to
the server machine). That’s why files you publish on the Web
must have special permission settings that make them accessible
to other users. It also means that some CGI scripts can’t rely
on the Python module search path to be configured in any
particular way. As you’ve learned by now, the module path is
normally initialized from the user’s
PYTHONPATH
setting and
.pth
files, plus defaults which normally
include the current working directory. But because CGI scripts
are run by the user “nobody,”
PYTHONPATH
may be arbitrary when a CGI
script runs.

Before you puzzle over this too hard, you should know that
this is often not a concern in practice. Because Python usually
searches the current directory for imported modules by default,
this is not an issue if all of your scripts and any modules and
packages they use are stored in your web directory, and your web
server launches CGI scripts in the directory in which they
reside. But if the module lives elsewhere, you may need to
modify the
sys.path
list in
your scripts to adjust the search path manually before
imports—for instance, with
sys.path.append(
dirname
)
calls, index assignments, and so
on.

End-of-line conventions
(optional)

On some Unix
(and Linux) servers, you might also have to make
sure that your script text files follow the Unix end-of-line
convention (
\n
), not DOS
(
\r\n
). This isn’t an issue
if you edit and debug right on the server (or on another Unix
machine) or FTP files one by one in text mode. But if you edit
and upload your scripts from a PC to a Unix server in a
tar
file (or in FTP binary mode), you may
need to convert end-of-lines after the upload. For instance, the
server that was used for the second edition of this text returns
a default error page for scripts whose end-of-lines are in DOS
format. See
Chapter 6
for
techniques and a note on automated end-of-line converter
scripts.

Unbuffered output streams
(optional)

Under some servers, the
print
call statement may buffer its
output. If you have a long-running CGI script, to avoid making
the user wait to see results, you may wish to manually flush
your printed text (call
sys.stdout.flush()
) or run your Python
scripts in unbuffered mode. Recall from
Chapter 5
that you can make streams
unbuffered by running with the
-u
command-line flag or by setting
your
PYTHON
UNBUFFERED
environment variable
to a nonempty value.

To use
-u
in the CGI
world, try using a first line on Unix-like platforms like
#!/usr/bin/python -u
. In
typical usage, output buffering is not usually a factor. On some
servers and clients, though, this may be a resolution for empty
reply pages, or premature end-of-script header errors—the client
may time out before the buffered output stream is sent (though
more commonly, these cases reflect genuine program errors in
your script).

This installation process may sound a bit complex at first
glance, but much of it is server-dependent, and it’s not bad once
you’ve worked through it on your own. It’s only a concern at install
time and can usually be automated to some extent with Python scripts
run on the server. To summarize, most Python CGI scripts are text
files of Python code, which:

  • Are named according to your web server’s conventions (e.g.,
    file.py
    )

  • Are stored in a directory recognized by your web server
    (e.g.,
    cgi-bin/
    )

  • Are given executable file permissions if required (e.g.,
    chmod 755 file.py
    )

  • May require the special
    #!
    pythonpath
    line at the top for some servers

  • Configure
    sys.path
    only
    if needed to see modules in other directories

  • Use Unix end-of-line conventions if your server rejects DOS
    format

  • Flush output buffers if required, or to send portions of the
    reply periodically

Even if you must use a server machine configured by someone
else, most of the machine’s conventions should be easy to root out
during a normal debugging cycle. As usual, you should consult the
conventions for any machine to which you plan to copy these example
files.

Finding Python on remote servers

One last install
pointer: even though Python doesn’t have to be installed
on any
clients
in the context of a server-side
web application, it does have to exist on the
server
machine where your CGI scripts are
expected to run. If you’re running your own server with either the
webserver.py
script we met earlier or an open
source server such as Apache, this is a nonissue.

But if you are using a web server that you did not configure
yourself, you must be sure that Python lives on that machine.
Moreover, you need to find where it is on that machine so that you can
specify its path in the
#!
line at
the top of your script. If you are not sure if or where Python lives
on your server machine, here are some tips:

  • Especially on Unix systems, you should first assume that
    Python lives in a standard place (e.g.,
    /usr/local/bin/python
    ): type
    python
    (or
    which python
    ) in a shell window and see
    if it works. Chances are that Python already lives on such
    machines. If you have Telnet or SSH access on your server, a Unix
    find
    command starting at
    /usr
    may help.

  • If your server runs Linux, you’re probably set to go. Python
    ships as a standard part of Linux distributions these days, and
    many websites and Internet Service Providers (ISPs) run the Linux
    operating system; at such sites, Python probably already lives at
    /usr/bin/python
    .

  • In other environments where you cannot control the server
    machine yourself, it may be harder to obtain access to an already
    installed Python. If so, you can relocate your site to a server
    that does have Python installed, talk your ISP into installing
    Python on the machine you’re trying to use, or install Python on
    the server machine yourself.

If your ISP is unsympathetic to your need for Python and you are
willing to relocate your site to one that is, you can find lists of
Python-friendly ISPs by searching the Web. And if you choose to
install Python on your server machine yourself, be sure to check out
the Python world’s support for
frozen
binaries
—with it, you can create a single executable
program file that contains the entire Python interpreter, as well as
all the standard library modules. Assuming compatible machines, such a
frozen interpreter might be uploaded to your web account by FTP in a
single step, and it won’t require a full-blown Python installation on
the server. The public domain PyInstaller and Py2Exe systems can
produce a frozen Python binary.

Finally, to run this book’s examples, make sure the Python you
find or install is Python 3.X, not Python 2.X. As mentioned earlier,
many commercial ISPs support the latter but not the former as I’m
writing this fourth edition, but this is expected to change over time.
If you do locate a commercial ISP with 3.X support, you should be able
to upload your files by FTP and work by SSH or Telnet. You may also be
able to run this chapter’s
webserver.py
script on the remote machine,
though you may need to avoid using the standard port 80, depending on
how much control your account
affords.

BOOK: Programming Python
13.75Mb size Format: txt, pdf, ePub
ads

Other books

A Life Less Ordinary by Bernadine, Victoria
Migratory Animals by Mary Helen Specht
Merely a Madness by Fairbrother, SW
Southern Comfort: Compass Brothers, Book 2 by Mari Carr and Jayne Rylon
The Cloak Society by Jeramey Kraatz
A Game of Shadows by Irina Shapiro
Just Joe by Marley Morgan
The Colonel by Mahmoud Dowlatabadi
My One And Only by MacKenzie Taylor


readsbookonline.com Copyright 2016 - 2024