<div dir="ltr">You probably just have to add 400 to errorpage.status_codes option in config<div><br></div><div>See <a href="http://turbogears.readthedocs.io/en/latest/reference/config-options.html#tg.appwrappers.errorpage.ErrorPageApplicationWrapper">http://turbogears.readthedocs.io/en/latest/reference/config-options.html#tg.appwrappers.errorpage.ErrorPageApplicationWrapper</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 23, 2016 at 8:34 PM, Thomas De Schampheleire <span dir="ltr"><<a href="mailto:patrickdepinguin@gmail.com" target="_blank">patrickdepinguin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alessandro,<br>
<br>
On Fri, Feb 19, 2016 at 10:14 PM, Thomas De Schampheleire<br>
<span class=""><<a href="mailto:patrickdepinguin@gmail.com">patrickdepinguin@gmail.com</a>> wrote:<br>
> On Thu, Feb 18, 2016 at 4:23 PM, Alessandro Molina<br>
> <<a href="mailto:alessandro.molina@gmail.com">alessandro.molina@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> On Thu, Feb 18, 2016 at 4:13 PM, Thomas De Schampheleire<br>
>> <<a href="mailto:patrickdepinguin@gmail.com">patrickdepinguin@gmail.com</a>> wrote:<br>
>>><br>
>>><br>
>>> So this means that Kallithea would start using the 'default' routing<br>
>>> method used by Turbogears projects?<br>
>>> Is this a big impact / does it require a lot of work, according to you?<br>
>><br>
>><br>
>> Nope, just that instead of relying RoutesMiddleware to run mapper.routematch<br>
>> and fill environ with routes variables (routes.url, routes.route,<br>
>> wsgiorg.routing_args) those should be filled by RootController itself.<br>
>><br>
>> Actually as I'm moving the routing logic from Kallithea to tgext.routes (so<br>
>> that Kallithea can just use it instead of implementing custom routing<br>
>> itself) that change is already undergoing, but I didn't have time to finish<br>
>> it so far.<br>
>><br>
>><br>
><br>
> Thanks, that sounds good...<br>
><br>
> Meanwhile I can confirm that my scenario with custom error pages work fine now.<br>
><br>
<br>
</span>Found a case where the custom error pages do not work, e.g. with this change:<br>
<br>
diff --git a/kallithea/controllers/home.py b/kallithea/controllers/home.py<br>
--- a/kallithea/controllers/home.py<br>
+++ b/kallithea/controllers/home.py<br>
@@ -67,6 +67,7 @@ class HomeController(BaseController):<br>
         #json used to render the grid<br>
         c.data = json.dumps(repos_data)<br>
<br>
+        raise HTTPBadRequest()<br>
         return render('/index.html')<br>
<br>
     @LoginRequired()<br>
<br>
<br>
and loading the home page, causes a plain page with text<br>
"400 Bad Request<br>
The server could not comply with the request since it is either<br>
malformed or otherwise incorrect."<br>
<br>
I verified that the same change on original Kallithea has the custom<br>
error page correctly displayed...<br>
<br>
Ideas?<br>
<br>
<br>
<br>
Meanwhile, the pytest migration has finished. I am planning to<br>
rebasing our current codebase on the latest Kallithea upstream to<br>
avoid making changes on obsolete code. Especially since I'm seeing<br>
many test failures with Turbogears2, and I expect that at least in<br>
some cases the test themselves should be fixed.<br>
This rebase could also incur some squashing of patches, to make it<br>
more ready for upstreaming. What do you think of that? And shall I<br>
push the result to your bitbucket repo or rather to another one?<br>
<br>
Thanks,<br>
Thomas<br>
</blockquote></div><br></div>