WSGI, CGI, Framework “A”, … and Apache

For the past week I have been attempting to implement a Django framework properly utilizing WSGI to prototype and develop webapps fast on a VPS I have running CentOS 7 and Apache 2.4 with cPanel/WHM. As with everything backend on a Terminal emulator on a one man team, it was a pain in the ass. I definitely learned a lot along the way towards my “”:

Although, there isn’t anything that beats a properly configured VPS/dedicated web server except for my potato. Jussst kidding. Obviously.

Anyways, I came across this Quora answer while sprucing up the brief knowledge of the topic I can confidently say isn’t too much at all. Obviously wanting to get over with the installation procedure while learning a buck or two worth of knowledge comes unfortunately and unusually–but usually–at the last minute or after the fact.

Say no more to newbie backend pains regarding the following, and it’s all no thanks to obscure, indirect explanations that fragment all these concepts from each other. Here it goes.

How WSGI, CGI, and the frameworks are all connected ?

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 or cherrypy) on my basic CGI configuration ?

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

  1. Embeddedmod_wsgi or mod_python embeds Python inside Apache; no process is forked. Apache runs the Django application directly.
  2. Daemonmod_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 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.

For background see this



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s