I did notice one 'race' condition; If you have an app that has an error in models/db.py
and you have */400 in routes.py your going to continuously be redirecting your self to the same page until the browsers own error handling kicks in and notifies of the problem;
Because in any page load your going to be throwing a 400 including the page you want to be redirect to; Unless of course your redirecting to a static page;
On 2/17/11 10:45 AM, Jonathan Lundell wrote:
A couple of questions have come up about routes_onerror in routes.py. Refreshing our memory, here's a fragment of routes.example.py: # Error-handling redirects all HTTP errors (status codes>= 400) to a specified # path. If you wish to use error-handling redirects, uncomment the tuple # below. You can customize responses by adding a tuple entry with the first # value in 'appName/HTTPstatusCode' format. ( Only HTTP codes>= 400 are # routed. ) and the value as a path to redirect the user to. You may also use # '*' as a wildcard. # # The error handling page is also passed the error code and ticket as # variables. Traceback information will be stored in the ticket. # # routes_onerror = [ # (r'init/400', r'/init/default/login') # ,(r'init/*', r'/init/static/fail.html') # ,(r'*/404', r'/init/static/cantfind.html') # ,(r'*/*', r'/init/error/index') # ] If you want to follow along in the source, this is used by rewrite.try_redirect_on_error, which is called at the end of a request by main.wsgibase. One thing I just noticed from looking at the path through the source is that, if the incoming URL doesn't conform to the main URL regex (and I'm talking about "normal" URL handling here, not the new URL router), routes_onerror is used when request.application is still set to None, which is now it's initialized. The status code will be 400. So if you want routes_onerror to be effective in this case, you'll need to have at least one entry with the application field set to '*' or to 'None' (the string representation of the None object). 'init/400', ... 'init/404', ... 'None'/400' ... Unless you have a specific reason not to, it's probably best to have a '*/*' catch-all case at the end as well. You never know... I'll be looking over the new router code with this in mind, but it's likely similar in operation.
