Description

In the interface definition of the router it is stated that an exception should be thrown when no route matches the request. Instead it is currently simply ignored, which leads the request to the default controller/action, instead of going to the error controller which could emit a 404 error then. This can surely only happen, when the default module route was removed, which is intendend when you only want your own routes to match to avoid duplicate content for search engines.

Comments

Posted by Ben Scholzen (dasprid) on 2009-12-21T07:15:49.000+0000

I've attached a patch for this issue, but there's a problem. By applying this patch, the following two tests in Zend_Controller_Router_RewriteTest are breaking:

testRouteNotMatches: Expects the route() method to return an unchanged request object, which has NULL as controller, action and module set. This will lead the front controller to dispatch the standard parameters (default/index/index), which is the actual issue we want to solve tho. So rewriting this test would actually be the test for the new (correct) behaviour.

testRemoveDefaultRoutes: This one doesn't like that much like a problem, since the routing is not tested at all here, while there's still a not-tested call done to the route() method (which would usually add a default route if not disabled). This means we would just have to wrap a try {} around the route() call, and the test would suceed again. This shouldn't affect reallife applications, since there will never be no routes, and if, they should lead to the error controller.

Posted by Ben Scholzen (dasprid) on 2009-12-21T07:58:42.000+0000

Attached new patch which solves the problem with front controller and error handler plugin.

Either this fix is wrong, since the old behaviour was actually just like I expected it to work, or my approach is wrong and can be achieved otherwise. Maybe force default values to the 'default' route.

Posted by Ben Scholzen (dasprid) on 2010-01-29T08:51:53.000+0000

Peter, can you please tell, how exacly your chain setup looked (code?). The changes of this issue should not have affected stuff like you show here.

Yeah, based on the initial 'bug' and fix I also thought this would not affect stuff. However (and my chain is rather simple) it appears to influence some behaviour (maybe the problem lies within the incorrect chaining of the 'default' route... either way, below the code that fails (two methods to create the default route chained behind my own initial route included, both fail)

Maybe the matching algorithm of a default route doesn't return that it matched anything when chained this way??