howto-webservers.pdf

HOWTOUsePythonintheweb

Release2.7.6

GuidovanRossum

FredL.Drake,Jr.,editor

March 17, 2014

PythonSoftwareFoundation

Email:docs@python.org

Contents

1TheLow-LevelView

1.1

Common Gateway Interface

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Simple script for testing CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Setting up CGI on your own server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iii

Common problems with CGI scripts

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iii

1.2

mod_python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

FastCGI and SCGI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Setting up FastCGI

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4

mod_wsgi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2Stepback:WSGI

2.1

WSGI Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Case study: MoinMoin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3Model-View-Controller

4IngredientsforWebsites

vii

4.1

Templates

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

4.2

Data persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii

5Frameworks

5.1

Some notable frameworks

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TurboGears

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Zope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Other notable frameworks

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Index xi

AuthorMarek Kubica

Abstract

This document shows how Python ﬁts into the web. It presents some ways to integrate Python with a web

server, and general practices useful for developing web sites.

Programming for the Web has become a hot topic since the rise of “Web 2.0”, which focuses on user-generated

content on web sites. It has always been possible to use Python for creating web sites, but it was a rather tedious

task. Therefore, many frameworks and helper tools have been created to assist developers in creating faster and

more robust sites. This HOWTO describes some of the methods used to combine Python with a web server to

create dynamic content. It is not meant as a complete introduction, as this topic is far too broad to be covered in

one single document. However, a short overview of the most popular libraries is provided.

SeeAlso:

While this HOWTO tries to give an overview of Python in the web, it cannot always be as up to date as desired.

Web development in Python is rapidly moving forward, so the wiki page on Web Programming may be more in

sync with recent development.

1TheLow-LevelView

When a user enters a web site, their browser makes a connection to the site’s web server (this is called therequest).

The server looks up the ﬁle in the ﬁle system and sends it back to the user’s browser, which displays it (this is the

response). This is roughly how the underlying protocol, HTTP, works.

Dynamic web sites are not based on ﬁles in the ﬁle system, but rather on programs which are run by the web

server when a request comes in, and whichgeneratethe content that is returned to the user. They can do all sorts

of useful things, like display the postings of a bulletin board, show your email, conﬁgure software, or just display

the current time. These programs can be written in any programming language the server supports. Since most

servers support Python, it is easy to use Python to create dynamic web sites.

Most HTTP servers are written in C or C++, so they cannot execute Python code directly – a bridge is needed

between the server and the program. These bridges, or rather interfaces, deﬁne how programs interact with the

server. There have been numerous attempts to create the best possible interface, but there are only a few worth

mentioning.

Not every web server supports every interface. Many web servers only support old, now-obsolete interfaces;

however, they can often be extended using third-party modules to support newer ones.

1.1CommonGatewayInterface

This interface, most commonly referred to as “CGI”, is the oldest, and is supported by nearly every web server out

of the box. Programs using CGI to communicate with their web server need to be started by the server for every

request. So, every request starts a new Python interpreter – which takes some time to start up – thus making the

whole interface only usable for low load situations.

The upside of CGI is that it is simple – writing a Python program which uses CGI is a matter of about three lines

of code. This simplicity comes at a price: it does very few things to help the developer.

Writing CGI programs, while still possible, is no longer recommended. With WSGI , a topic covered later in this

document, it is possible to write programs that emulate CGI, so they can be run as CGI if no better option is

available.

SeeAlso:

The Python standard library includes some modules that are helpful for creating plain CGI programs:

• cgi – Handling of user input in CGI scripts

• cgitb – Displays nice tracebacks when errors happen in CGI applications, instead of presenting a “500

Internal Server Error” message

The Python wiki features a page on CGI scripts with some additional information about CGI in Python.

SimplescriptfortestingCGI

To test whether your web server works with CGI, you can use this short and simple CGI program:

#!/usr/bin/envpython

#- * -coding:UTF-8- * -

#enabledebugging

import cgitb

cgitb . enable()

print "Content-Type:text/plain;charset=utf-8"

print "HelloWorld!"

Depending on your web server conﬁguration, you may need to save this code with a .py or .cgi extension.

Additionally, this ﬁle may also need to be in a cgi-bin folder, for security reasons.

You might wonder what the cgitb line is about. This line makes it possible to display a nice traceback instead

of just crashing and displaying an “Internal Server Error” in the user’s browser. This is useful for debugging,

but it might risk exposing some conﬁdential data to the user. You should not use cgitb in production code for

this reason. You shouldalwayscatch exceptions, and display proper error pages – end-users don’t like to see

nondescript “Internal Server Errors” in their browsers.

SettingupCGIonyourownserver

If you don’t have your own web server, this does not apply to you. You can check whether it works as-is, and if

not you will need to talk to the administrator of your web server. If it is a big host, you can try ﬁling a ticket asking

for Python support.

If you are your own administrator or want to set up CGI for testing purposes on your own computers, you have

to conﬁgure it by yourself. There is no single way to conﬁgure CGI, as there are many web servers with different

conﬁguration options. Currently the most widely used free web server is Apache HTTPd , or Apache for short.

Apache can be easily installed on nearly every system using the system’s package management tool. lighttpd is

another alternative and is said to have better performance. On many systems this server can also be installed using

the package management tool, so manually compiling the web server may not be needed.

• On Apache you can take a look at the Dynamic Content with CGI tutorial, where everything is described.

Most of the time it is enough just to set +ExecCGI . The tutorial also describes the most common gotchas

that might arise.

• On lighttpd you need to use the CGI module , which can be conﬁgured in a straightforward way. It boils

down to setting cgi.assign properly.

CommonproblemswithCGIscripts

Using CGI sometimes leads to small annoyances while trying to get these scripts to run. Sometimes a seemingly

correct script does not work as expected, the cause being some small hidden problem that’s difﬁcult to spot.

Some of these potential problems are:

• The Python script is not marked as executable. When CGI scripts are not executable most web servers will

let the user download it, instead of running it and sending the output to the user. For CGI scripts to run prop-

erly on Unix-like operating systems, the +x bit needs to be set. Using chmoda+xyour_script.py

may solve this problem.

• On a Unix-like system, The line endings in the program ﬁle must be Unix style line endings. This is

important because the web server checks the ﬁrst line of the script (called shebang) and tries to run the

program speciﬁed there. It gets easily confused by Windows line endings (Carriage Return & Line Feed,

also called CRLF), so you have to convert the ﬁle to Unix line endings (only Line Feed, LF). This can be

done automatically by uploading the ﬁle via FTP in text mode instead of binary mode, but the preferred way

is just telling your editor to save the ﬁles with Unix line endings. Most editors support this.

• Your web server must be able to read the ﬁle, and you need to make sure the permissions are correct. On

unix-like systems, the server often runs as user and group www-data , so it might be worth a try to change

the ﬁle ownership, or making the ﬁle world readable by using chmoda+ryour_script.py .

• The web server must know that the ﬁle you’re trying to access is a CGI script. Check the conﬁguration of

your web server, as it may be conﬁgured to expect a speciﬁc ﬁle extension for CGI scripts.

• On Unix-like systems, the path to the interpreter in the shebang ( #!/usr/bin/envpython ) must be

correct. This line calls /usr/bin/env to ﬁnd Python, but it will fail if there is no /usr/bin/env ,

or if Python is not in the web server’s path. If you know where your Python is installed, you can also use

that full path. The commands whereispython and type-ppython could help you ﬁnd where it

is installed. Once you know the path, you can change the shebang accordingly: #!/usr/bin/python .

• The ﬁle must not contain a BOM (Byte Order Mark). The BOM is meant for determining the byte order of

UTF-16 and UTF-32 encodings, but some editors write this also into UTF-8 ﬁles. The BOM interferes with

the shebang line, so be sure to tell your editor not to write the BOM.

• If the web server is using mod_python , mod_python may be having problems. mod_python is able to

handle CGI scripts by itself, but it can also be a source of issues.

1.2mod_python

People coming from PHP often ﬁnd it hard to grasp how to use Python in the web. Their ﬁrst thought is mostly

mod_python , because they think that this is the equivalent to mod_php . Actually, there are many differences.

What mod_python does is embed the interpreter into the Apache process, thus speeding up requests by not hav-

ing to start a Python interpreter for each request. On the other hand, it is not “Python intermixed with HTML” in the

way that PHP is often intermixed with HTML. The Python equivalent of that is a template engine. mod_python

itself is much more powerful and provides more access to Apache internals. It can emulate CGI, work in a “Python

Server Pages” mode (similar to JSP) which is “HTML intermingled with Python”, and it has a “Publisher” which

designates one ﬁle to accept all requests and decide what to do with them.

mod_python does have some problems. Unlike the PHP interpreter, the Python interpreter uses caching when

executing ﬁles, so changes to a ﬁle will require the web server to be restarted. Another problem is the basic

concept – Apache starts child processes to handle the requests, and unfortunately every child process needs to

load the whole Python interpreter even if it does not use it. This makes the whole web server slower. Another

problem is that, because mod_python is linked against a speciﬁc version of libpython , it is not possible to

switch from an older version to a newer (e.g. 2.4 to 2.5) without recompiling mod_python . mod_python

is also bound to the Apache web server, so programs written for mod_python cannot easily run on other web

servers.

These are the reasons why mod_python should be avoided when writing new programs. In some circumstances

it still might be a good idea to use mod_python for deployment, but WSGI makes it possible to run WSGI

programs under mod_python as well.

1.3FastCGIandSCGI

FastCGI and SCGI try to solve the performance problem of CGI in another way. Instead of embedding the

interpreter into the web server, they create long-running background processes. There is still a module in the web

server which makes it possible for the web server to “speak” with the background process. As the background

process is independent of the server, it can be written in any language, including Python. The language just needs

to have a library which handles the communication with the webserver.

The difference between FastCGI and SCGI is very small, as SCGI is essentially just a “simpler FastCGI”. As the

web server support for SCGI is limited, most people use FastCGI instead, which works the same way. Almost

everything that applies to SCGI also applies to FastCGI as well, so we’ll only cover the latter.

These days, FastCGI is never used directly. Just like mod_python , it is only used for the deployment of WSGI

applications.

SeeAlso:

• FastCGI, SCGI, and Apache: Background and Future is a discussion on why the concept of FastCGI and

SCGI is better than that of mod_python.

SettingupFastCGI

Each web server requires a speciﬁc module.

• Apache has both mod_fastcgi and mod_fcgid . mod_fastcgi is the original one, but it has some licensing

issues, which is why it is sometimes considered non-free. mod_fcgid is a smaller, compatible alternative.

One of these modules needs to be loaded by Apache.

• lighttpd ships its own FastCGI module as well as an SCGI module .

• nginx also supports FastCGI .

Once you have installed and conﬁgured the module, you can test it with the following WSGI-application:

#!/usr/bin/envpython

#- * -coding:UTF-8- * -

from cgi import escape

import sys , os

from flup.server.fcgi import WSGIServer

def app (environ,start_response):

start_response( ’200OK’ ,[( ’Content-Type’ , ’text/html’ )])

yield ’<h1>FastCGIEnvironment</h1>’

yield ’<table>’

for k,v in sorted (environ . items()):

yield ’<tr><th> %s </th><td> %s </td></tr>’ % (escape(k),escape(v))

yield ’</table>’

WSGIServer(app) . run()

This is a simple WSGI application, but you need to install ﬂup ﬁrst, as ﬂup handles the low level FastCGI access.

SeeAlso:

There is some documentation on setting up Django with FastCGI , most of which can be reused for other WSGI-

compliant frameworks and libraries. Only the manage.py part has to be changed, the example used here can be

used instead. Django does more or less the exact same thing.

1.4mod_wsgi

mod_wsgi is an attempt to get rid of the low level gateways. Given that FastCGI, SCGI, and mod_python are

mostly used to deploy WSGI applications, mod_wsgi was started to directly embed WSGI applications into the

Apache web server. mod_wsgi is speciﬁcally designed to host WSGI applications. It makes the deployment of

WSGI applications much easier than deployment using other low level methods, which need glue code. The down-

side is that mod_wsgi is limited to the Apache web server; other servers would need their own implementations

of mod_wsgi.

mod_wsgi supports two modes: embedded mode, in which it integrates with the Apache process, and daemon

mode, which is more FastCGI-like. Unlike FastCGI, mod_wsgi handles the worker-processes by itself, which

makes administration easier.

2Stepback:WSGI

WSGI has already been mentioned several times, so it has to be something important. In fact it really is, and now

it is time to explain it.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: