Web Server Gateway Interface: Difference between revisions

Content deleted Content added

Inline

Revision as of 02:54, 22 November 2011

The Web Server Gateway Interface (WSGI) (sometimes pronounced as 'wiz-gee' or 'whiskey') defines a simple and universal interface between web servers and web applications or frameworks for the Python programming language.

Idea

Historically, Python web application frameworks have been a problem for new Python users because, generally speaking, the choice of web framework would limit the choice of usable web servers, and vice versa. Python applications were often designed for either CGI, FastCGI, mod_python or even custom API interfaces of specific web-servers.

WSGI^[1] was created as a low-level interface between web servers and web applications or frameworks to promote common ground for portable web application development.

Specification overview

The WSGI has two sides: the “server” or “gateway” side, and the “application” or “framework” side. The server side calls the application side, providing environment information plus a callback function (for the application to use to convey headers to the server side), and receiving web content in return.

So-called WSGI middleware implements both sides of the API so that it can intermediate between a WSGI server and a WSGI application: the middleware acts as an application from some WSGI server's point of view and as a server from some WSGI application's point of view. A “middleware” component can perform such functions as:

Routing a request to different application objects based on the target URL, after changing the environment variables accordingly.
Allowing multiple applications or frameworks to run side-by-side in the same process
Load balancing and remote processing, by forwarding requests and responses over a network
Perform content postprocessing, such as applying XSLT stylesheets

Example application

A WSGI-compatible “Hello World” application written in Python:

def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    yield 'Hello World\n'

Where:

Line 1 defines a callable^[2] named application, which takes two parameters, environ and start_response. environ is a dictionary containing environment variables in CGI. start_response is a callable taking two required parameters status and response_headers.
Line 2 calls start_response, specifying “200 OK” as the status and a “Content-Type” header.
Line 3 returns the body of response as a string literal.

Example of calling an application

An example of calling an application and retrieving its response:

def call_application(app, environ):
    body = []
    status_headers = [None, None]
    def start_response(status, headers):
        status_headers[:] = [status, headers]
        return body.append
    app_iter = app(environ, start_response)
    try:
        for item in app_iter:
            body.append(item)
    finally:
        if hasattr(app_iter, 'close'):
            app_iter.close()
    return status_headers[0], status_headers[1], ''.join(body)

status, headers, body = call_application(app, {...environ...})

WSGI-compatible applications and frameworks

There are numerous web application frameworks supporting WSGI:

Wrappers

The server or gateway invokes the application callable once for each request it receives from an HTTP client, that is directed at the application.

Currently wrappers are available for FastCGI, CGI, SCGI, AJP (using flup), twisted.web, Apache (using mod_wsgi or mod_python) and Microsoft IIS (using isapi-wsgi, PyISAPIe, or an ASP gateway).

WSGI and Python 3

The separation of binary and text data in Python 3 poses a problem for WSGI, as it specifies that header data should be strings, while it sometimes needs to be binary and sometimes text. This works in Python 2 where text and binary data both are kept in "string" variables, but in Python 3 binary data is kept in "bytes" variables and "string" variables are for unicode text data. An updated version of the WSGI specification that deals with this is PEP 3333. ^[6]

A reworked WSGI spec Web3 has also been proposed, specified in PEP444. This standard is an incompatible derivative of WSGI designed to work on Python 2.6, 2.7, 3.1+.^[7]

References

^ PEP 3333, Python Web Server Gateway Interface v1.0
^ Throughout this specification, we will use the term “a callable” to mean “a function, method, class, or an instance with a __call__ method”.
^ [1] Django with WSGI support
^ [2] Bottle Micro-Framework
^ [3] weblayer package for writing WSGI application
^ PJ Eby. "PEP 3333". Retrieved 2011-07-27.
^ Chris McDonough, Armin Ronacher (2010-09-16). "PEP 444 -- Python Web3 Interface". Retrieved 2010-09-20.

External links

[1] PEP 3333, Python Web Server Gateway Interface v1.0

[2] Throughout this specification, we will use the term “a callable” to mean “a function, method, class, or an instance with a __call__ method”.

[djangowsgi-3] [1] Django with WSGI support

[bottle-4] [2] Bottle Micro-Framework

[weblayer-5] [3] weblayer package for writing WSGI application

[6] PJ Eby. "PEP 3333". Retrieved 2011-07-27.

[7] Chris McDonough, Armin Ronacher (2010-09-16). "PEP 444 -- Python Web3 Interface". Retrieved 2010-09-20.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

@@ Line 60: / Line 60: @@
 * [[Pylons (web framework)|Pylons]]
 * [[BlueBream]]
-* [[nginx]]
 * [[Google App Engine]]{{Dubious|date=June 2011}}
 * [[Trac]]