Issue #455 resolved

Enable CP's WSGI server for middleware (and other WSGI related enhancements)

Christian Wyglendowski
created an issue

Patch attached.


  1. cherrypy.server.start() accepts a new parameter; middleware. The middleware wraps (potentially other middleware and) _cpwsgi.wsgiApp.
  2. The path to the CherryPy app now occupies the WSGI PATH_INFO variable (as opposed to SCRIPT_NAME). I am not a WSGI expert, but this should keep CherryPy from "owning" the root path of the request and allows other apps (and middleware) to coexist better with it.
  3. cherrypy.request.wsgi_environ now contains the WSGI environ for the request. This is immediately useful for WSGI session middleware and could be for other WSGI middleware that wants to share data structures, etc, with wrapped apps.

The CP test suite passes with the patch applied.

I am only beginning to "get" the WSGI PEP, so I might have made some incorrect assumptions. Please see the attached patch and example application and give me feedback.

Comments (7)

  1. Christian Wyglendowski reporter

    My wsgi_filter also works with this patch and allows WSGI application "stacks" like the following:

       . |PyBloxsom wsgi app| wsgi app  | |
      /|\+------------------+------------------+ |  R
    R  | +-------------------------------------+ |  E
    E  | |           _cpwsgi.wsgiApp           | |  S
    Q  | +-------------------------------------+ |  P
    U  | +-------------------------------------+ |  O
    E  | |          SessionMiddleware          | |  N
    S  | +-------------------------------------+ |  S
    T  | +-------------------------------------+\|/ E
       | |            EvalException            | '

    That offers some nice flexibility, IMO. Sessions could be shared between a CherryPy and app. Exceptions in the CherryPy app, !PyBloxsom or the app will be caught by !EvalException for interactive debugging.

  2. Robert Brewer

    I understand the need for this, but I don't think _cpserver is the right place for it; that is, _cpserver shouldn't special-case the constructor signature of *any* HTTP server. If you need to pass args to an HTTP server's init (or otherwise modify the server before it's started), that should either by done by the caller (with a subclass of WSGIServer, or a factory function, for example), or server.start should be modified to accept server instances as well as server classes (which would be my vote).

    In another ticket and changeset, by the way, I'm making the base WSGIServer multi-app aware; that is, you will be able to configure it to call different WSGI app callables for different mount_points. So the _cpserver.Server.wsgi_app attribute will be too limiting when that happens. If you like, I can make the above changes in that changeset.

  3. Christian Wyglendowski reporter

    That sounds fine to me. Thanks for your thoughts on the matter. Go ahead and make the changes as you suggested. I'm also really interested to see your multiapp changes to _cpwsgiserver.

  4. Log in to comment