Ticket #719 (defect)
Opened 1 year ago
Last modified 10 months ago
RoutesDispatcher not working correctly
Status: closed (fixed)
| Reported by: | pstradomski@gmail.com | Assigned to: | rdelon |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | CherryPy code | Keywords: | routes dispatcher |
| Cc: |
Routes dispatcher in 3.0.2 currently fails when generaing urls with url_for() function. The reason behind this behaviour is that WSGIEnvProxy object is not subscriptable.
This can be solved by adding three more methods to WSGIEnvProxy class:
def get(self, key, fallback = None):
if key in cherrypy.request.wsgi_environ:
return cherrypy.request.wsgi_environ[key]
else:
return fallback
def __contains__(self, key):
return key in cherrypy.request.wsgi_environ
def __getitem__(self, key):
return cherrypy.request.wsgi_environ[key]
But this does in fact still use an unnecessary workaround. The WSGIEnvProxy is not needed because routes is thread safe. It is sufficient to change
self.mapper.environ = WSGIEnvProxy()
in RoutesDispatcher? to
if hasattr(cherrypy.request, 'wsgi_environ'):
config.environ = cherrypy.request.wsgi_environ
Such use is recommended by Routes documentation. The WSGIEnvProxy class can be dropped altogether.
The if hasattr(...) is there because during server self-tests requests are made without wsgi_environ, perhaps this should be fixed too.
Change History
08/24/07 12:24:27: Modified by fumanchu
08/27/07 15:29:59: Modified by pstradomski@gmail.com
During server startup some tests are automatically run. Unfortunately they do not set wsgi_environ (I guess they should, probably another bug). One of the tests tries to fetch /dummy.html. This of course goes to dispatcher, which then fails because there is no wsgi_environ on cherrypy.request. I just added this hack to make server start up. (otherwise it would just block in the same way as it does when one mounts an app without any configuration).
10/27/07 23:22:38: Modified by fumanchu
- status changed from new to closed.
- resolution set to fixed.
Fixed in [1791].


Makes sense, except for the last bit about the hasattr. Can you elaborate on the situations when wsgi_environ would not be present? Perhaps it would be more appropriate for "server self-tests" to set request.wsgi_environ; otherwise, you're not testing anything but your own hacks to get around proper testing... ;)