WSGI

Answer 1:

SCGI (like FastCGI) is a (serialized) protocol suitable for inter-process communication between a web-server and a web-application.

WSGI is a Python API, connecting two (or more) Python WSGI-compatible modules inside the same process (Python interpreter). One module represents the web-server (being either a Python in-process web-server implementation or a gateway to a web-server in another process via e.g. SCGI). The other module is or represents the web application. Additionally, zero or more modules between theses two modules, may serve as WSGI "middleware" modules, doing things like session/cookie management, content caching, authentication, etc. The WSGI API uses Python language features like iteration/generators and passing of callable objects between the cooperating WSGI-compatible modules.

Answer 2:

The high-level goal of a server is this:

1. Accept a request
2. Process the request
3. Send a response

Many web servers  (i.e. Apache, Nginx, etc) are used primarily for just accepting requests. They can target specific ports and protocols to receive these requests.

Next, there are  web applications , which take data from the request, acts on it, and prepares data for the response.  These applications can be written in any language as long as there is the necessary "glue" between it and the web server. 

For example, Django is a web application framework that can use WSGI glue to bind itself to an apache web server. In other words, WSGI connects two different pieces of software so they play nicely. As a result, we have 2 modular systems, which is nice.  

Now, you are probably asking: what is this glue? The glue is not another piece of software; the glue is an  agreement between the web server and the web application .

Ansewer 3:

FastCGI is a deployment option on servers like nginx, lighttpd, and cherokee; seeuWSGI and Standalone WSGI Containers for other options. To use your WSGI application with any of them you will need a FastCGI server first. The most popular one is flup which we will use for this guide. Make sure to have it installed to follow along.

Ansewer 4:

Apache listens on port 80. It gets an HTTP request. It parses the request to find a way to respond. Apache has a LOT of choices for responding. One way to respond is to use CGI to run a script. Another way to respond is to simply serve a file.

In the case of CGI, Apache prepares an environment and invokes the script through the CGI protocol. This is a standard Unix Fork/Exec situation -- the CGI subprocess inherits an OS environment including the socket and stdout. The CGI subprocess writes a response, which goes back to Apache; Apache sends this response to the browser.

CGI is primitive and annoying. Mostly because it forks a subprocess for every request, and subprocess must exit or close stdout and stderr to signify end of response.

WSGI is an interface that is based on the CGI design pattern. It is not necessarily CGI -- it does not have to fork a subprocess for each request. It can be CGI, but it doesn't have to be.

WSGI adds to the CGI design pattern in several important ways. It parses the HTTP Request Headers for you and adds these to the environment. It supplies any POST-oriented input as a file-like object in the environment. It also provides you a function that will formulate the response, saving you from a lot of formatting details.

What do I need to know / install / do if I want to run a web framework (say web.py or cherrypy) on my basic CGI configuration ?

Recall that forking a subprocess is expensive. There are two ways to work around this.

1. Embedded mod_wsgi or mod_python embeds Python inside Apache; no process is forked. Apache runs the Django application directly.

2. Daemon mod_wsgi or mod_fastcgi allows Apache to interact with a separate daemon (or "long-running process"), using the WSGI protocol. You start your long-running Django process, then you configure Apache's mod_fastcgi to communicate with this process.

Note that mod_wsgi can work in either mode: embedded or daemon.

When you read up on mod_fastcgi, you'll see that Django uses flup to create a WSGI-compatible interface from the information provided by mod_fastcgi. The pipeline works like this.

Apache -> mod_fastcgi -> FLUP (via FastCGI protocol) -> Django (via WSGI protocol)

Django has several "django.core.handlers" for the various interfaces.

For mod_fastcgi, Django provides a manage.py runfcgi that integrates FLUP and the handler.

For mod_wsgi, there's a core handler for this.

How to install WSGI support ?

Follow these instructions.

http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

For background see this

http://docs.djangoproject.com/en/dev/howto/deployment/#howto-deployment-index