Ticket #455 (enhancement)
Opened 2 years ago
Last modified 2 years ago
Enable CP's WSGI server for middleware (and other WSGI related enhancements)
Status: closed (fixed)
| Reported by: | dowski | Assigned to: | dowski |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | CherryPy code | Keywords: | |
| Cc: | christian@dowski.com |
Patch attached.
Changes:
- cherrypy.server.start() accepts a new parameter; middleware. The middleware wraps (potentially other middleware and) _cpwsgi.wsgiApp.
- 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.
- 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.
Attachments
Change History
01/29/06 16:08:48: Modified by dowski
01/29/06 16:17:36: Modified by dowski
- cc set to christian@dowski.com.
- status changed from new to assigned.
01/30/06 16:01:00: Modified by dowski
- attachment full_patch_on_rev949.diff added.
updated to support cherrypy.request.wsgi_eviron
01/30/06 16:05:58: Modified by dowski
- attachment app_with_middleware.py added.
Example app using EvalException? and session middleware
01/31/06 09:28:08: Modified by dowski
- description changed.
02/06/06 06:27:29: Modified by dowski
- attachment wsgi_modifications_on_rev956.diff added.
updated patch (removed stuff about cp loading other wsgi apps natively)
02/06/06 06:29:45: Modified by dowski
- attachment test_new_wsgiserver.py added.
demo of new wsgiserver features
02/07/06 17:55:34: Modified by fumanchu
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.
02/07/06 20:07:20: Modified by dowski
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.
02/07/06 20:31:36: Modified by dowski
- status changed from assigned to closed.
- resolution set to fixed.
My wsgi_filter also works with this patch and allows WSGI application "stacks" like the following:
+------------------+------------------+ . |PyBloxsom wsgi app| web.py 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 web.py app. Exceptions in the CherryPy app, PyBloxsom or the web.py app will be caught by EvalException for interactive debugging.