Zend Framework

Actually, the current behavior is correct. When the useDefaultControllerAlways is set to true, then isDispatchable() will always return true – because it will resolve the invalid or empty controller to the default controller. I've tested extensively, and it works exactly as expected.

The one issue I've had with this is if I set the parameter after dispatch() has already been called on the front controller – i.e., from a plugin. In such a case, by the time that routeStartup() has hit, pushing the parameters into the front controller will have no effect on the router or dispatcher. If this is what you are doing, you may need to push that setParam() into your bootstrap or index.php prior to calling dispatch().

Sorry, I can't agree with You. My bootstrap.php:
$frontController = Zend_Controller_Front::getInstance();
$frontController->throwExceptions(true);
$frontController->setRouter($router);
$frontController->setParam('noViewRenderer', true);
$frontController->setParam('useDefaultControllerAlways', true);
$frontController->setControllerDirectory('../application/modules/default/controllers');
$frontController->registerPlugin(...some plugins here...);

$frontController->returnResponse(true);
$response = $frontController->dispatch();

/My own class for handling headers./
$response->sendResponse();

And let's try my code, set $frontController->setParam('useDefaultControllerAlways', false); and go to http://domain/non/existent > Invalid controller specified. Now $frontController>throwExceptions(false); -> Action "error" does not exist and was not trapped in __call(). W can read http://framework.zend.com/manual/en/zend.controller.exceptions.html "By default, the error handler plugin is registered and active...By passing a boolean true value to this method, you can tell the front controller that instead of aggregating exceptions in the response object or using the error handler plugin, you'd rather handle them yourself.". So as You can see everything is working as it should.

Now use default ZF code. $frontController->setParam('useDefaultControllerAlways', false); and go to http://domain/non/existent > index/index was loaded. Why? $frontController>throwExceptions(false); -> index/index . Nothing is working. You can also search google - there are several sites where people complain of such strange behavior.

I have done exactly what you suggest: I used a stock ZF install, with only an IndexController and ErrorController defined, and set the useDefaultControllerAlways param to false. In such a case, passing an invalid controller correctly goes to the ErrorController. Toggling the flag to true, I correctly go to the IndexController. This is exactly the behavior that is expected.

That said, I think I know where the confusion lies: when an action is also provided via the URL. Let's look at the flow:

• invalid controller detected
• controller rewritten to IndexController
• action called on IndexController
• IndexController does not find action method, and invokes __call()
• __call() recognizes that an undefined action was called, and throws an exception
• the ErrorHandler plugin detects the exception and invokes the ErrorController

So, the useDefaultControllerAlways flag is doing exactly as it should. The problem is that there is an expectation that the action controller will fall back to a default action as well. And that's the real issue here.

I'm re-opening the issue and noting that when the default controller is selected in such a case that the default action as defined in the dispatcher should also be utilized.

It was some time ago when I reported this bug so I forgot real problem here was $router->removeDefaultRoutes(). What You said is valid for general, default routes. Could You please explain to me what exactly should happen if we changed ZF default routing?

Resolved in r12822 in trunk and r12823 in 1.7 release branch

I can confirm this. Removing the default routes, the error controller is never called. Changing "!empty($controller)" to "empty($controller)", as suggested by the bug reporter, fixed the issue for me too.

This bug is marked as resolved, but I can still reproduce it in the latest release (1.8.1). As reported by Marek, the problem happens when calling $router->removeDefaultRoutes(), and can be fixed by removing the "!" sign from within the "!empty($controller)" check.

Still in 1.8.4
Zend\Controller\Dispatcher\Standard.php

line 239 :
if (!$this->getParam('useDefaultControllerAlways') && !empty($controller)) {

new line 239 :
if (!$this->getParam('useDefaultControllerAlways') && empty($controller)) {

same problem here, Zend Framework 1.8.1

For us this worked to disable the default routing in some projects:

Index: libs/zfw-1_8_1/Zend/Controller/Dispatcher/Standard.php
===================================================================
--- libs/zfw-1_8_1/Zend/Controller/Dispatcher/Standard.php      (revision 5938)
+++ libs/zfw-1_8_1/Zend/Controller/Dispatcher/Standard.php      (working copy)
@@ -236,9 +236,14 @@
          */
         if (!$this->isDispatchable($request)) {
             $controller = $request->getControllerName();
-            if (!$this->getParam('useDefaultControllerAlways') && !empty($controller)) {
+            # see: http://framework.zend.com/issues/browse/ZF-3465
+            if (!$this->getParam('useDefaultControllerAlways')) {
                 require_once 'Zend/Controller/Dispatcher/Exception.php';
-                throw new Zend_Controller_Dispatcher_Exception('Invalid controller specified (' . $request->getControllerName() . ')');
+                if(!empty($controller)) {
+                    throw new Zend_Controller_Dispatcher_Exception('Invalid controller specified (' . $request->getControllerName() . ')');
+                } else {
+                    throw new Zend_Controller_Dispatcher_Exception('No controller determined and useDefaultControllerAlways is disabled!');
+                }
             }

             $className = $this->getDefaultControllerClass($request);