On Feb 17, 2011, at 7:53 AM, David J. wrote: > > 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;
Good point. One consequence of that is that it's probably a good idea not to use error redirection during development (except of course when you're testing error redirection); even if it doesn't loop, it's likely to confuse the error more than clarify it. I'm not sure how one would break the error loop. I was thinking maybe adding an http header line, but the request for the error page is ultimately the result of a redirection, so there's no http request for us to get our hands on. > > > > > > 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. >
