Zend_Controller_Request_Http provides a request object for use in an HTTP environment. Zend_Controller_Request_Http is the default request class utilised by Zend_Controller_Dispatcher.

Zend_Controller_Request_Http encapsulates access to relevant values such as the key name and value for the controller and action router variables, and all additional parameters parsed from the URI. By proxying to Zend_Controller_Request_Http it additionally allows access to values contained in the superglobals as public members and manages the current Base URL and Request URI. Superglobal values cannot be set on a request object, instead use the setParam/getParam methods to set or retrieve user parameters.

	Superglobal data
	When accessing superglobal data through Zend_Controller_Request_Http as public member properties, it is necessary to keep in mind that the property name (superglobal array key) is matched to a superglobal in a specific order of precedence: 1. GET, 2. POST, 3. COOKIE, 4. SERVER, 5. ENV.

Specific superglobals can be accessed using a public method as an alternative. For example, the raw value of $_POST['user'] can be accessed by calling getPost('user') on the request object.

Zend_Controller_Request_Http allows Zend_Controller_Router_Rewrite to be used in subdirectories. Zend_Controller_Request_Http will attempt to automatically detect your base URL and set it accordingly.

For example, if you keep your index.php in a webserver subdirectory named /projects/myapp/index.php, base URL (rewrite base) should be set to /projects/myapp. This string will then be stripped from the beginning of the path before calculating any route matches. This frees one from the necessity of prepending it to any of your routes. A route of 'user/:username' will match URIs like http://localhost/projects/myapp/user/martel and http://example.com/user/martel.

	URL detection is case sensitive
	Automatic base URL detection is case sensitive, so make sure your URL will match a subdirectory name in a filesystem (even on Windows machines). If it doesn't you will get to noRoute action.

Should base URL be detected incorrectly you can override it with your own base path with the help of the setBaseUrl() method of either the Zend_Controller_Request_Http class, or the Zend_Controller_Front class. The easiest method is to set it in Zend_Controller_Front, which will proxy it into the request object. Example usage to set a custom base URL:

/**
 * Dispatch Request with custom base URL with Zend_Controller_Front.
 */
$router     = new Zend_Controller_Router_Rewrite();
$controller = Zend_Controller_Front::getInstance();
$controller->setControllerDirectory('./application/controllers')
           ->setRouter($router)
           ->setBaseUrl('/projects/myapp'); // set the base url!
$response   = $controller->dispatch();

Zend_Controller_Router_Rewrite is the standard framework router. Routing is the process of taking a URI endpoint (that part of the URI which comes after the base URL) and decomposing it into parameters to determine which controller and action of that controller should receive the request. This value of the controller, action and other parameters is packaged into a Zend_Controller_Request_Http object which is then processed by Zend_Controller_Dispatcher_Standard. Routing occurs only once: when the request is initially received and before the first controller is dispatched.

Zend_Controller_Router_Rewrite is designed to allow for mod_rewrite like functionality using pure php structures. It is very loosely based on Ruby on Rails routing and does not require any prior knowledge of webserver URL rewriting. It is designed to work with a single Apache mod_rewrite rule (one of):

RewriteEngine on
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

or:

RewriteEngine on
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 

The rewrite router can also be used with the IIS webserver if Isapi_Rewrite has been installed as an Isapi extension with the following rewrite rule:

RewriteRule ^[\w/\%]*(?:\.(?!(?:js|ico|gif|jpg|png|css)$)[\w\%]*$)? /index.php [I]

	IIS Isapi_Rewrite
	When using IIS, $_SERVER['REQUEST_URI'] will either not exist, or be set as an empty string. In this case, Zend_Controller_Request_Http will attempt to use the $_SERVER['HTTP_X_REWRITE_URL'] value set by the Isapi_Rewrite extension.

If using Lighttpd, the following rewrite rule is valid:

url.rewrite-once = ( ".*\.(js|ico|gif|jpg|png|css)$" => "$0", "" => "/index.php")

To properly use the rewrite router you have to instantiate it, add some user defined routes and inject it into the controller. The following code illustrates the procedure:

/* Create a router */

$router = $ctrl->getRouter(); // returns a rewrite router by default
$router->addRoute(
    'user',
    new Zend_Controller_Router_Route('user/:username', array('controller' => 'user', 'action' => 'info'))
);

The heart of the RewriteRouter is the definition of user defined routes. Routes are added by calling the addRoute method of RewriteRouter and passing in a new instance of a class implementing Zend_Controller_Router_Route_Interface. Eg.:

$router->addRoute('user', new Zend_Controller_Router_Route('user/:username'));

Rewrite Router comes with four basic types of routes (one of which is special):

Routes may be used numerous times to create a chain or user defined application routing schema. You may use any number of routes in any configuration, with the exception of Module route which should rather be used once and probably as the most generic route (ie. as a default). Each route will be described in greater detail later on.

The first parameter to addRoute is the name of the route. It is used as a handle for getting the routes out of the router, eg. for URL generation purposes. The second parameter being the route itself.

	Note
	The most common use of the route name is through the means of Zend_View url helper: <a href="<?= $this->url('user', array('username' => 'martel')) ?>">Martel</a> Which would result in href of: user/martel

Routing is a simple process of iterating through all provided routes and matching it's definitions to current request URI. When a positive match is found, variable values are returned from the Route instance and are injected into Zend_Controller_Request object for later use in dispatcher as well as in user created controllers. On a negative match next route in chain is checked.

	Reverse matching
	Routes are matched in reverse order so make sure your most generic routes are defined first.

	Returned values
	Values which are returned from routing come from URL parameters or user defined route defaults. These variables are later accessible through a Zend_Controller_Request::getParam or Zend_Controller_Action::_getParam methods.

There are three special variables which can be used in your routes - 'module', 'controller' and 'action'. These special variables are used by Zend_Controller_Dispatcher to find a controller and action to dispatch to.

	Special variables
	Names of these special variables may be different if you choose to alter the defaults in Zend_Controller_Request_Http by the means of setControllerKey and setActionKey methods.

Zend_Controller_Router_Rewrite comes preconfigured with a default route, which will match URIs in the shape of controller/action. Additionally, a module name may be specified as the first path element, allowing URIs of the form module/controller/action. Finally, it will also match any additional parameters appended to the URI by default - controller/action/var1/value1/var2/value2.

Some examples of how such routes are matched:

// Assuming the following:
$ctrl->setControllerDirectory(
    array(
        'default' => '/path/to/default/controllers',
        'news'    => '/path/to/blog/controllers',
        'blog'    => '/path/to/blog/controllers'
    )
);

Module only:
http://example/news
    module == news

Invalid module maps to controller name:
http://example/foo
    controller == foo

Module + controller:
http://example/blog/archive
    module     == blog
    controller == archive

Module + controller + action:
http://example/blog/archive/list
    module     == blog
    controller == archive
    action     == list

Module + controller + action + params:
http://example/blog/archive/list/sort/alpha/date/desc
    module     == blog
    controller == archive
    action     == list
    sort       == alpha
    date       == desc

The default route is simply a Zend_Controller_Router_Route_Module object stored under the name (index) of 'default' in RewriteRouter. It's created more-or-less like below:

$compat = new Zend_Controller_Router_Route_Module(array(), $dispatcher, $request);
$this->addRoute('default', $compat);

If you do not want this particular default route in your routing schema, you may override it by creating your own 'default' route (ie. storing it under the name of 'default') or removing it altogether by using removeDefaultRoutes():

// Remove any default routes
$router->removeDefaultRoutes();

The rewrite router can be used in subdirectories (eg. http://domain.com/~user/application-root/>) in which case the base URL of the application (/~user/application-root) should be automatically detected by Zend_Controller_Request_Http and used accordingly.

Should the base URL be detected incorrectly you can override it with your own base path with the help of Zend_Controller_Request_Http by calling the setBaseUrl() method (see Section 7.4.2.3, “Base Url and subdirectories”):

$request->setBaseUrl(/~user/application-root/);

Zend_Controller_Router_Route is a standard framework route which combines ease of use with flexible route definition. Each route consists primarily of URL mapping (of static and dynamic parts (variables)) and may be initialized with defaults as well as with variable requirements.

Let's imagine our fictional application will need some informational page about the content authors. We want to be able to point our web browsers to http://domain.com/author/martel to see the information about this "martel" guy. And route for such functionality could look like:

$route = new Zend_Controller_Router_Route(
             'author/:username', 
             array('controller' => 'profile', 'action' => 'userinfo')
         );

$router->addRoute('user', $route);

First parameter in the Zend_Controller_Router_Route constructor is a route definition that will be matched to a URL. Route definition consists of static and dynamic parts separated by the slash ('/') character. Dynamic parts, called variables, are marked by the colon prepended to the variable name (eg. :username). Static parts are just a simple text (eg. author).

	Character usage
	Current implementation allows you to use any characters (except a slash) as a variable identifier but it is strongly recommended that one uses only php variable friendly characters. Implementation may be altered in the future which could result in hidden bugs in your code.

This example route should be matched when you point your browser to 'http://domain.com/author/martel' in which case all it's variables will be injected to the Zend_Controller_Request object and will be accessible in your ProfileController. Variables returned by this example may be represented as an array of following key and value pairs:

$values = array(
  'username' => 'martel',
  'controller' => 'profile',
  'action' => 'userinfo'
);

Later on Zend_Controller_Dispatcher should invoke userinfoAction method of your ProfileController class (in default module) based on these values. There you will be able to access all variables by the means of Zend_Controller_Action::_getParam or Zend_Controller_Request::getParam methods:

public function userinfoAction() 
{
    $request = $this->getRequest();
    $username = $request->getParam('username');
    
    $username = $this->_getParam('username');
}

Route definition can contain one more special character - a wildcard - represented by '*' symbol. It is used to gather parameters similarly to Module route (var => value pairs defined in the URI). Following route mimicks Module route behavior:

$route = new Zend_Controller_Router_Route(':controller/:action/*');
$router->addRoute('default', $route);

$route = new Zend_Controller_Router_Route(
             'archive/:year', 
             array(
                 'year' => 2006
             )
         );
$router->addRoute('archive', $route);

$route = new Zend_Controller_Router_Route(
             'archive/:year', 
             array(
                 'year' => 2006, 
                 'controller' => 'archive',
                 'action' => 'show'
             )
         );
$router->addRoute('archive', $route);

$route = new Zend_Controller_Router_Route(
             'archive/:year', 
             array(
                 'year' => 2006, 
                 'controller' => 'archive',
                 'action' => 'show'
             ),
             array('year' => '\d+')
         );
$router->addRoute('archive', $route);

With route defined like above, Rewrite Router will match it only when the year variable will contain numeric data, eg. http://domain.com/archive/2345. URL of http://example.com/archive/test will not be matched and control will be passed to the next route in chain instead.

The examples above all use dynamic routes -- routes that contain patterns to match against. Sometimes, however, a particular route is set in stone, and firing up the regular expression engine would be an overkill. The answer to this situation is to use static routes:

$route = new Zend_Controller_Router_Route_Static(
             'login', 
             array('controller' => 'auth', 'action' => 'login')
         );
$router->addRoute('login', $route);

Above route will match a URL of http://domain.com/login

In addition to the default and static route types, a Regular Expression route type is available. This route offers more power and flexibility over the others, but at a slight cost of complexity. And should be faster than a standard Route at the same time.

As well as the standard route, this route has to be initialized with route definition and some defaults. Let's create an archive route as an example, similar to the previoulsy defined one, only using Regex route this time:

$route = new Zend_Controller_Router_Route_Regex(
             'archive/(\d+)', 
             array(
                 'controller' => 'archive',
                 'action' => 'show'
             )
         );
$router->addRoute('archive', $route);

Every defined regex subpattern will be injected to the request object. With our above example, after successful matching http://domain.com/archive/2006, the resulting value array may look like:

$values = array(
  1 => '2006',
  'controller' => 'archive',
  'action' => 'show'
);

	Note
	Leading and trailing slashes are trimmed from the URL in the Router prior to a match. As a result, matching the URL http://domain.com/foo/bar/, would involve a regex of foo/bar.

	Note
	Line start and line end anchors ('^' and '$', respectively) are automatically pre- and appended to all expressions. Thus, you should not use these in your regular expressions.

	Note
	This route class uses the # character for a delimiter. This means that you will need to escape hash characters ('#') in your route definitions. But since these characters aren't passed to the webserver (named anchors), you will rarely need to do so.

You can get the contents of the defined subpatterns the usual way:

public function showAction() 
{
    $request = $this->getRequest();
    $year = $request->getParam(1); // $year = '2006';
}

	Note
	Notice the key is an integer (1) instead of a string ('1').

This route will not yet work exactly the same as it's standard route counterpart since the default for 'year' is not yet set. And what may not yet be evident we will have a problem with a trailing slash even if we declare default for the year and make the subpattern optional. The solution is to make the whole year part optional along with the slash but catch only the numeric part:

$route = new Zend_Controller_Router_Route_Regex(
             'archive(?:/(\d+))?', 
             array(
                 'year' => '2006',
                 'controller' => 'archive',
                 'action' => 'show'
             )
         );
$router->addRoute('archive', $route);

Now let's get to the problem you have probably noticed on your own by now. Using integer based keys for parameters is not an easily manageable solution and may be potentially problematic in the long run. And that's where the third parameter comes in. One which represents a map of regex subpatterns to parameter named keys. Let's work on our easier example:

$route = new Zend_Controller_Router_Route_Regex(
             'archive/(\d+)', 
             array(
                 'controller' => 'archive',
                 'action' => 'show'
             ),
             array(
                1 => 'year'
             )
         );
$router->addRoute('archive', $route);

This will result in following values injected into Request:

$values = array(
  'year' => '2006',
  'controller' => 'archive',
  'action' => 'show'
);

The map may be defined in both ways to make it work in any environment (eg. Zend_Config). Keys may contain variable names or subpattern numbers.

	Note
	Subpattern keys have to be represented by integers

$route = new Zend_Controller_Router_Route_Regex(
             'archive/(\d+)', 
             array( ... ),
             array(
                1 => 'year'
             )
         );

// OR
         
$route = new Zend_Controller_Router_Route_Regex(
             'archive/(\d+)', 
             array( ... ),
             array(
                'year' => 1
             )
         );       

Notice that the numeric index in Request values is now gone and a named variable is shown in it's place. Of course you can mix numeric and named variables if you wish:

$route = new Zend_Controller_Router_Route_Regex(
             'archive/(\d+)/page/(\d+)', 
             array( ... ),
             array(
                'year' => 1
             )
         );       

Which will result in mixed values available in the Request. Example URL http://domain.com/archive/2006/page/10 will result in following values:

$values = array(
  'year' => '2006',
  2 => 10,
  'controller' => 'archive',
  'action' => 'show'
);

Since regex is not easily reversed, you will need to prepare reverse URL if you wish to use an url helper or even an assemble method of this class. This reversed path is represented by a string parsable by sprintf() and is defined as a fourth construct parameter:

$route = new Zend_Controller_Router_Route_Regex(
             'archive/(\d+)', 
             array( ... ),
             array(
                'year' => 1
             ),
             'archive/%s'
         );       

All of this is something which was already possible by the means of a standard route object, so where's the benefit in using Regex Route, you ask? You can describe any type of URL without any restrictions. Imagine you have a blog and wish to create URLs like: http://domain.com/blog/archive/01-Using_the_Regex_Router.html. Now that's something which was not possible before, is it? Here's the solution:

$route = new Zend_Controller_Router_Route_Regex(
             'blog/archive/(\d+)-(.+)\.html',
             array('controller' => 'blog', 'action' => 'view'), 
             array(1 => 'id', 2 => 'description'),
             'blog/archive/%d-%s.html'
         );
$router->addRoute('blogArchive', $route);

Sometimes its more convenient to update a configuration file with new routes than to change the code. This is possible via the addConfig() method. Basically, you create a Zend_Config-compatible configuration, and in your code read it in and pass it to the RewriteRouter:

As an example, consider the following INI file:

[production]
routes.archive.route = "archive/:year/*"
routes.archive.defaults.controller = archive
routes.archive.defaults.action = show
routes.archive.defaults.year = 2000
routes.archive.reqs.year = "\d+"

routes.news.type = "Zend_Controller_Router_Route_Static"
routes.news.route = "news"
routes.news.defaults.controller = "news"
routes.news.defaults.action = "list"

routes.archive.type = "Zend_Controller_Router_Route_Regex"
routes.archive.route = "archive/(\d+)"
routes.archive.defaults.controller = "archive"
routes.archive.defaults.action = "show"
routes.archive.map.1 = "year" 
; OR: routes.archive.map.year = 1

The above INI file can then be read into a Zend_Config object as follows:

$config = new Zend_Config_Ini('/path/to/config.ini', 'production');
$router = new Zend_Controller_Router_Rewrite();
$router->addConfig($config, 'routes');

In the above example, we tell the router to use the 'routes' section of the INI file to use for its routes. Each first-level key under that section will be used to define a route name; the above example defines the routes 'archive' and 'news'. Each route then requires, minimally a 'route' entry and one or more 'defaults' entries; optionally one or more 'reqs' (short for 'required') may be provided. All told, these correspond to the three arguments provided to a Zend_Controller_Router_Route_Interface object. An option key, 'type', can be used to specify the route class type to use for that particular route; by default, it uses Zend_Controller_Router_Route. In the example above, the 'news' route is defined to use Zend_Controller_Router_Route_Static.