Introducing WSGI: Python's Secret Web Weapon
Web Server Gateway Interface Part I: Getting Started
In this two-part article, we will look at what the Web Server Gateway Interface is, how to use it to write web applications, and how to use middleware components to quickly add powerful functionality. Before diving into these topics, we will also take a brief look at why the specification was created in the first place.
The Many Frameworks Problem
Python is a great language for web development. It is straightforward to learn, has a broad and powerful standard library, and benefits from an active community of developers who maintain a range of XML and database tools, templating languages, servers, and application frameworks. In 2003, when the Web Server Gateway Interface specification was drawn up, the Python community also had one major problem. It was often easier for developers to write their own solutions to web-development problems from scratch rather than reusing and improving existing projects. This resulted in a proliferation of largely incompatible web frameworks. If developers wanted a full and powerful solution, they could use Zope, but many of them coming into the community in search of a lightweight framework found it hard to know where to start.
Developers within the Python community quickly recognized that it would be preferable to have fewer and better-supported frameworks, but since each framework had its strengths and weaknesses at the time, none stood out as a clear candidate for adoption.
In the Java world, the servlet architecture meant that applications written with one framework could run on any server supporting the servlet API. The Web Server Gateway Interface (often written WSGI, pronounced "whiskey") was designed to bring the same interoperability that the Java world enjoyed to Python, and to go some way toward unifying the Python web-framework world without stifling the diversity.
The full specification is defined in PEP 333. (PEP is an acronym for Python Enhancement Proposal.) The abstract of the PEP sums up the specification's goals very clearly, stating:
"This document specifies a proposed standard interface between web servers and Python web applications or frameworks, to promote web application portability across a variety of web servers."
Most Python web frameworks today have a WSGI adapter, and most server technologies (Apache, mod_python, FastCGI, CGI, etc.) can be used to run WSGI applications, so the vision of web-application portability is fast becoming a reality.
The separation of server from application has the clear benefit that application developers supporting the API do not have to worry about how their applications are served, and server developers need only create one interface to support the majority of Python web applications. Simply supporting the WSGI is enough for server and application developers to guarantee a large degree of interoperability.
In the next sections, we will look at how to develop and deploy WSGI applications; in Part II of this article, we will look at how to use middleware components to provide facilities such as session handling, interactive debugging, and much more.
The HTTP Protocol
The Web is largely built on the HTTP protocol, so to understand the WSGI, it is essential to understand how the Web works at the HTTP protocol level.
It is very useful to be able to see the HTTP information being sent back and forth between a web browser and a server. One good tool for doing this is the LiveHTTPHeaders extension for the Firefox web browser which, when loaded, is visible in the sidebar and displays the HTTP information sent and received on each request. Once it's installed, you can select
View->Sidebar->LiveHTTPHeaders from the menu to load the extension in the sidebar.
When you request a page, the browser sends an HTTP request to the server. When the server receives that request, it will perform some action (typically running an application or serving a file) and return an HTTP response. Below is the HTTP information sent when visiting the PEP 333 page:
Figure 1. HTTP Request
and here is the response returned:
Figure 2. HTTP Response
As you can see, the browser sends quite a lot of information to the server. The server makes this and other information available to the application. The application then returns a status code (in this case,
200 OK) along with any HTTP headers it wishes to send back. Of particular note is the
Content-type header, which tells the browser what sort of content is going to be sent (in this case,
text/html). Finally, the application returns the content that will be displayed by the browser (in this case, the HTML that makes up the page). The server may add extra HTTP headers or perform other modifications before the response is returned.
Pages: 1, 2