Issue #600 resolved

InternalRedirect does double duty

Robert Brewer
created an issue

!InternalRedirect switches from one handler to another. For some time now (at least since [1400]) !InternalRedirect has been schizophrenic, being asked to handle two very different needs:

  1. Those cases that require path_info to be rewritten. !CherryPy 3 has no use cases for this; all have come entirely from user applications.
  2. Those cases that requre path_info to ''not'' be rewritten. This includes the virtual host tool and the XML-RPC tool. These should not rewrite path_info because that then affects systems like cherrypy.url, which expect the original path_info. See [1428] for an example of a test that fails when virtual_host is implemented using !InternalRedirect.

My recommendation is that these two needs be met with separate features. The attached patch changes virtual host and xmlrpc, implementing them via dispatch wrapper functions instead of hooks + !InternalRedirect. This leaves !InternalRedirect free to meet only those cases which require path_info to be rewritten. There has been some discussion lately of dropping !InternalRedirect, or possibly reimplementing it to use multiple Request objects in order to avoid some of the hook reentry madness described [http://groups.google.com/group/cherrypy-devel/msg/9ab4833f7c7dd5d4 here]. This patch allows that decision to proceed without losing any current !CherryPy functionality.

Comments (4)

  1. Robert Brewer reporter

    The [http://www.cherrypy.org/attachment/ticket/600/forward.patch forward.patch] goes a step further, moving the handling of !InternalRedirect from the Request object out to the code which calls Request.run. See _cptree for the new redirect loop. This allows a single HTTP request to potentially create multiple Request obejcts to get the job done; the most important benefit of this is that each Request object can be properly finalized, including all hooks.

    This patch also removes Request.redirections in favor of a (modpython-style) Request.prev attribute, which points to the previous Request object; adding the .next attribute might be helpful but was left out for now.

  2. Log in to comment