Django comes with its own lightweight web server, which is written in Python. This is a great tool for quick testing or during development, but I would strongly advise against using it in a production environment. I have never encountered any problems while using it, but as the developers behind Django say, they are in the web frameworks business and are not here to develop robust web servers.
One of the most obvious choices for a web server is the Apache web service. It is widespread and used on the vast majority of web sites on the Internet. Apache installation packages are included by default on many Linux distributions. It is easy to set up Apache in such a way that it serves both static CSS stylesheets and images and dynamically generated pages (as in a Django application). Our example will assume the following information:
• Name of the web site: www.example. com
• Directory where Django code is stored: / var/app/vhosts/www.example. com/
• Directory where static contents are stored: /var/www/vhosts/www_example_com/
■Note You may wonder why the code and contents directories are separate. The reason for separation is that it's an additional security measure. As you will see later in the chapter, we will instruct the web server to call the mod_python module for all requests made to the virtual server. The exception will be all URIs starting with /static/, which will be our static content. Now, if for some reason we make a mistake in the configuration file so that mod_python is not called and the code directory is part of the DocumentRoot directive, all our Python files will become downloadable. So, always keep your code files separate and outside DocumentRoot!
Listing 3-1 shows the VirtualServer definition in the Apache web server configuration file. Depending on your Linux distribution, this section may be included directly in httpd. conf or as a separate configuration file alongside other VirtualServer definitions.
Listing 3-1. The VirtualServer definition for the Django web application
<VirtualHost 192.168.0.1:80> ServerName www.example.com
PythonHandler django.core.handlers.modpython PythonPath sys.path+['/var/app/virtual/'] SetEnv DJANGO_SETTINGS_MODULE www_example_com.settings SetEnv PYTHON_EGG_CACHE /tmp <Location "/static/">
SetHandler None </Location> </VirtualHost>
The first section of the configuration deals with basic configuration, such as setting server name, base directory for all static contents and log file locations.
This is followed by mod_python configuration, where the first line tells Apache to pass execution of each web server phase to the mod_python module:
This directive is followed by the module configuration settings.
WHAT ARE APACHE HANDLERS?
Every request that is received by an Apache web server is processed in phases. For example, a request to a simple index.html file may involve three phases: translate the URI to the absolute location of the file; read the file and send it in an HTTP response; and finally log the event. The phases involved in each request depend on the server configuration. Each phase is processed by a handler. Apache server has only basic handlers; more complicated functions are implemented by handlers that are part of loadable modules, one of them being mod_python. The Python module has handlers for all possible Apache phases, but by default no handlers are called. Each phase needs to be associated specifically with the appropriate handler in the configuration file.
Django requires only one handler, the generic PythonHandler, which is invoked during the phase when actual content is provided and served to the requestor. The Django framework comes with its own handler and does not require the default mod_python. publisher handler. The following statement tells Apache to call Django's handler:
Was this article helpful?