Yet better would be to retain the actual HTTP status code when rewriting/redirecting.
Which would mean to only change the response body into the "friendly" error page (unless the application has already provided a body in the http object), and leave the status code as it is. Someone a more trivial suggestion? E.g. can routes_onerror be suspended just for the current request? Dominic On 23 Sep, 22:16, Dominic <dominic.koe...@googlemail.com> wrote: > Hi-- > > "Friendly error pages" :) may be user-friendly, but they break > requests from non-interactive clients, because those cannot parse the > error pages, and moreover, they will never know that there was an > error (they always get a 200 OK or a 303 SEE OTHER, but never a 400 > BAD REQUEST or 401 UNAUTHORIZED or the like). > > Non-interactive clients (e.g. based on urllib2) may have Auth-handlers > installed which expect a 401 challenge in order to trigger sending of > credentials. If that challenge never comes, they can never login. > However, for interactive requests, we still want a redirection to the > login page. > > Is there a way to override routes_onerror just for the current request > (e.g. if the app finds out that the request comes from a non- > interactive client)? > > Dominic
