URL-rewriting in CherryPy 2.1 and TurboGears

Oct 27, 2005 13:15 · 334 words · 2 minute read

Robert “FuManChu” Brewer goes in-depth on URL-rewriting in CherryPy 2.1. This is some documentation I wish I had a couple weeks ago. Robert sums up which aspects of mounting apps at arbitrary points are broken:

  1. Generating URL’s to spit back out in HTML. Broken. I now have to manually provide prefix to my HTML templates, or take on the nightmare of making every generated URL into a URL which is relative (e.g. “../../otherpage”) to the current one.

  2. HTTP Redirects and their targets. Broken. I now have to manually provide prefix to each instance (or use relative URL’s). But I can’t control CherryPy’s redirect instances! For example, when CherryPy tries to redirect index methods by adding a trailing slash to the requested URI, it uses the value of path, which I’ve rewritten.

  3. Handler dispatch: not broken.

  4. Arbitrary mount points: not broken.

  5. Config lookups. Broken? Some other filter which does a config lookup could run their onStartResource method before mine. Since my filter is user-defined, it is forced to run after all of the builtin ones; none of those currently perform config lookups, however. If any of the server.* config entries are specified somewhere other than “global”, then we have the same issue. Finally, what’s to stop a future CP developer from adding more such problems (as they fix other bugs)?

  6. Logging: the error.log and access.log will both use the original URI (from requestLine). Broken? or not? One? Both?

I should note that TurboGears has a fix for #1 and #2 on the list, in the form of an included URL generation function that takes the application root into account. #2 is actually only partly fixed by the URL function. CherryPy’s built in trailing slash redirect knows nothing about my little URL function. There’s a ticket open in the TurboGears Trac about static resources in mounted apps that is basically consideration #5 on Robert’s list. I hadn’t looked at the logging aspect of the problem, so I’ll definitely take Robert’s word on the state of it.