Skip to main content
Help us improve Python packaging – donate today!

WSGI middleware for caching responses to disk.

Project Description

wsgi_cache is a piece of WSGI middleware that provides disk caching for WSGI applications. It is somewhat coarse and rather inflexible, sort of like your grandpa.

wsgi_cache is designed to cache requests to a WSGI site to disk in a cache directory on disk. The cache directory will have the same directory layout as the requests (ie, if /foo/bar is requested, the foo directory will be made in the cache and bar will be stored there). There is no cache expiration beyond deleting cached files from the disk. This is a feature.


wsgi_cache can be installed as a Python egg, using easy_install:

$ easy_install wsgi_cache


Configuration of wsgi_cache will often be done using Paste Deploy. In this situation, it can be configured as a filter:

use = egg:my_wsgi_app#app
filter-with = cache

use = egg:wsgi_cache#middleware
cache_dir = ./cache

The cache_dir is the only required configuration parameter, and will be interpreted as relative to global_conf['here'].

wsgi_cache also supports three additional configuration parameters:

  • content_type
    Specifies the content type used when serving cached resources; see Limitations below for details on this. By default this is set to text/html.
  • cache_paths
    A comma separated list of paths, starting with a /, that specifies the paths to cache. If specified, only requests to paths starting with one of these strings will be cached.
  • directory_index
    When accessing a path that ends in a / (like /monkeys/), wsgi_cache needs to create a special filename. By default this is __index.html. So by default, caching the page /monkeys/ saves to the file ${path_to_cache}/monkeys/__index.html; if we set directory_index to dir_x it would save to ${path_to_cache}/monkeys/dirx.


When a request comes in, wsgi_cache examines the path to determine if it should be cached. Requests with a querystring are not cached, regardless of the use of cache_paths. If the request is supposed to be cached, wsgi_cache looks for the page in the cache and serves that copy, if available. If unavailable, the request is passed to the application and the result is saved and returned.

Note that in many situations, you’ll want to exploit wsgi_cache’s on disk cache layout to serve the cached version directly using your front end web server (ie, Apache with mod_rewrite).


wsgi_cache may be developed using buildout

$ python
$ ./bin/buildout

This will install any dependencies, as well as create a wrapper python script that can be used to run a shell with wsgi_cache on the Python path.

Running Tests

wsgi_cache uses nose for running tests. You can run the test suite by running:

$ python nosetests

If you’re using buildout for development, nose will be installed in the buildout for you:

$ ./bin/python nosetests


  • wsgi_cache only stores the response body in order to allow serving of the cached files by a faster, static webserver. As such, it can only return a single content-type at this point.


Release history Release notifications

This version
History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


Download files

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

Filename, size & hash SHA256 hash help File type Python version Upload date
wsgi_cache-0.2.3-py2.6.egg (6.5 kB) Copy SHA256 hash SHA256 Egg 2.6 Jul 27, 2011
wsgi_cache-0.2.3.tar.gz (7.7 kB) Copy SHA256 hash SHA256 Source None Jul 27, 2011

Supported by

Elastic Elastic Search Pingdom Pingdom Monitoring Google Google BigQuery Sentry Sentry Error logging CloudAMQP CloudAMQP RabbitMQ AWS AWS Cloud computing Fastly Fastly CDN DigiCert DigiCert EV certificate StatusPage StatusPage Status page