Skip to main content

A WSGI middleware which processes ESI directives

Project description

wesgi implements an ESI Processor as a WSGI middeware. It is primarily aimed at development environments to simulate the production ESI Processor. Under certain conditions it may be used in production as well.

Completeness

This implementation currently only implements <esi:include> and <!--esi --> comments. The relevant specifications and documents are:

Performance

An ESI processor generally makes a lot of network calls to other services in the process of putting together a page. So, in general, to reach very high levels of performance it should be asynchronous. Standard Python and WSGI is synchronous, placing an upper limit on performance which depends on the following:

  • How many threads are used

  • How many ESI includes used per page

  • The speed of the servers serving the ESI Includes

  • Whether wesgi uses a cache and if the ESI includes come with Cache-Control headers

Depending on the situation, wesgi may be performant enough for you.

There are also a number of ways to run WSGI applications asynchronously, with varying definitions of “asynchronous”.

Usage

>>> from wesgi import MiddleWare
>>> from wsgiref.simple_server import demo_app

To use it in it’s default configuration for a development server:

>>> app = MiddleWare(demo_app)

To simulate an Akamai Production environment:

>>> app = MiddleWare(demo_app, policy='akamai')

To simulate an Akamai Production environment with “chase redirect” turned on:

>>> from wesgi import AkamaiPolicy
>>> policy = AkamaiPolicy()
>>> policy.chase_redirect = True
>>> app = MiddleWare(demo_app, policy=policy)

If you wish to use it for a production server, it’s advisable to turn debug mode off and enable some kind of cache:

>>> from wesgi import LRUCache
>>> from wesgi import Policy
>>> policy.cache = LRUCache()
>>> app = MiddleWare(demo_app, debug=False, policy=policy)

The LRUCache is a memory based cache using an approximation of the LRU algorithm. The good parts of it were inspired by Raymond Hettinger’s lru_cache recipe.

Other available caches that can be easily integrated are httplib2’s FileCache or memcache. See the httplib2 documentation for details.

Development

Development on wesgi is centered around this github branch:

https://github.com/jinty/wesgi

CHANGES

0.8 (2011-07-07)

Features

  • A max_object_size option for wesgi.LRUCache to limit the maximum size of objects stored.

0.7 (2011-07-06)

Features

  • Major refactoring to use httplib2 as the backend to get ESI includes. This brings along HTTP Caching.

  • A memory based implementation of the LRU caching algoritm at wesgi.LRUCache.

  • Handle ESI comments.

Bugfixes

  • Fix bug where regular expression to find src:includes could take a long time.

0.5 (2011-07-04)

  • Initial release.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

wesgi-0.8.tar.gz (9.4 kB view hashes)

Uploaded Source

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page