Erle Robotics Python Networking Gitbook Free

WSGI Middleware

Standard interfaces like WSGI make it possible for developers to create wrappers—a design-patterns person would call these adapters—that accept a request from a server; modify, adjust, or record the request; and then call a normal WSGI application with the modified environment. Such middleware can also inspect and adjust the outgoing data stream; everything, in fact, is up for grabs, and essential arbitrary changes can be made both to the circumstances under which a WSGI application runs, as well as to the content that it returns.

  • If several WSGI applications need to live at a single web site under different URLs, then a piece of middleware can be given the URLs. (you can read more in
  • If each WSGI application on a web site were to keep its own list of passwords and honor only its own session cookies, then users would have to log in again each time they crossed an application boundary. By delegating authentication to WSGI middleware, applications can be relieved even of the duty to provide their own login page; instead, the middleware asks a user who lacks a session cookie to log in; once a user is authenticated, the middleware can pass along the user's identity to the applications by putting the user's information in the environ argument. Both repoze.who and repoze.what can help site integrators assert site-wide control over users and their permissions.
  • Theming can be a problem when several small applications are combined to form a larger web site. This is because each application typically has its own approach to theming.This has led to the development of two competing tools, xdv and Deliverance, that let you build a single HTML theme and then provide simple rules that pull text out of your back-end applications and drop it into your theme in the right places.
  • Debuggers can be created that call a WSGI application and, if an uncaught Python exception is raised, display an annotated traceback to support debugging. WebError actually provides the developer with a live, in-browser Python command line prompt for every level in a stack trace at which the developer can investigate a failure. Another popular tool is repoze.profile, which watches the application as it processes requests and produces a report on which functions are consuming the most CPU cycles.

If you are interested in what WSGI middleware is available, then you can visit this pair of sites to learn more:

Today there are at least three major competing approaches in the Python community for crafting modular components that can be used to build web sites:

  • The WSGI middleware approach thinks that code reuse can often best be achieved through a component stack, where each component uses WSGI to speak to the next. Here, all interaction has to somehow be made to fit the model of a dictionary of strings being handed down and then content being passed back up.
  • Everything built atop the Zope Toolkit uses formal Design Pattern concepts like interfaces and factories to let components discover one another and be configured for operation. Thanks to adapters, components can often be used with widgets that were not originally designed with a given type of component in mind.
  • Several web frameworks have tried to adopt conventions that would make it easy for third-party pieces of functionality to be added to an application easily. The Django community seems to have traveled the farthest in this direction, but it also looks as though it has encountered quite serious roadblocks in cases where a component needs to add its own tables to the database that have foreign-key relationships with user tables.

These examples illustrate an important fact: WSGI middleware is a good idea that has worked very well for a small class of problems where the idea of wrapping an application with concentric functionality makes solid sense. However, most web programmers seem to want to use more typical Python mechanisms like APIs, classes, and objects to combine their own code with existing components.