I am also experiencing this "issue". I see this in routes.example.py:
--snip-- # In the event that the error-handling page itself returns an error, web2py will # fall back to its old static responses. You can customize them here. # ErrorMessageTicket takes a string format dictionary containing (only) the # "ticket" key. --snip-- Is that referring to an error with the "error_handler" action, or the "routes_onerror" tuple? I guess what I'm asking is the redirect loop expected, or should web2py be catching the error and failing back to the default error message/page? --Marc On Thu, Feb 17, 2011 at 11:20 AM, Jonathan Lundell <jlund...@pobox.com> wrote: > 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. >> > > >
