ZF-288: Enable Router to work without relying on mod_rewrite (or equivalent for other web servers)

Description

For example, combining .htaccess, http://httpd.apache.org/docs/2.2/…, and $_SERVER['PATH_INFO'], it is possible to extremely efficiently map http://www.foo.com/something.php/* to a ZF bootstrap script without the overhead of mod_rewrite.

This issue is not about which approach is better. A non-trivial percentage of potential ZF users will not be able to use mod_rewrite for one of several possible reasons. If we support an alternative, then some portion of those users will be able to use ZF.

Comments

First things first - current solution (RewriteRouter) allows you to use the framework without mod_rewrite. URLs like 'http://test.nebula.intranet/index.php/archive/…' and 'http://localhost/test/index.php/archive/2006/07' will just work.

The problem with pure path_info is that you don't have access to the rewrite base (eg. 'test/index.php') so you can't get correct URLs for your application root (to use for img, css, js, etc). But since it's a standard CGI environment variable, it's definately worth checking out as a possible source of getting the base out of the request URI (by stripping path_info). This may prevent the hacks needed to bypass this bug (or feature):

http://bugs.php.net/bug.php?id=38141 http://issues.apache.org/bugzilla/show_bug.cgi/…

Oh, and one more thing - this does seem not to work on IIS. Is there an equivalent of AcceptPathInfo on that server software?

Gavin, I have tried to use PATH_INFO for the task but it seems the bug also touches this one.

If you place your RewriteRules under or in .htaccess everything works. But if you place it directly under you get:

For the root dir:

$_SERVER['DOCUMENT_ROOT'] = '/var/www/localhost/htdocs/test' $_SERVER['SCRIPT_FILENAME'] = '/var/www/localhost/htdocs/test/index.php' $_SERVER['REQUEST_URI'] = '/' $_SERVER['SCRIPT_NAME'] = '' $_SERVER['PATH_INFO'] = '/index.html' // OMG!

For deeper URL (see request_uri) where PATH_INFO should be initialized (notice SCRIPT_NAME is still wrong):

$_SERVER['DOCUMENT_ROOT'] = '/var/www/localhost/htdocs/test' $_SERVER['SCRIPT_FILENAME'] = '/var/www/localhost/htdocs/test/index.php' $_SERVER['REQUEST_URI'] = '/archive/2006/05' $_SERVER['SCRIPT_NAME'] = '' $_SERVER['PATH_INFO'] = '/archive/2006/05'

Of course SCRIPT_NAME should be '/index.php' in both of these cases.

And about the PathInfo on IIS. It is possible to make it work: http://support.microsoft.com/kb/184320/EN-US/

Long story short, everything which needs to be done is to:

  1. Change to the following directory (depending on platform): Windows 2000: Drive:\inetpub\adminscripts Windows NT 4: Drive:\winnt\system32\inetsrv\adminsamples

  2. Type the following: adsutil set w3svc/AllowPathInfoForScriptMappings True (Sets at Master Properties Level) adsutil set w3svc/1/AllowPathInfoForScriptMappings True (Sets at WebSite Level)

And voila.

I have written several web applications in the past without using mod_rewrite, instead using $_SERVER['PATH_INFO'], and have not had a problem referencing images, CSS, and Javascript files from within an application accessed via http://www.foo.com/index.php/something/goes/here. However, there are numerous external inconsistencies in the environmental input provided to PHP. Thus we must find test conditions and patterns amongst $_SERVER[] variables in order to make this work.

I don't expect PATH_INFO to solve everyone's problems, but merely to provide another possible way for the ZF to work on their deployment platform, thus increasing the probability they can succeed when trying to install ZF applications. Within a couple years, the majority of deployments of the ZF might be end users deploying ZF applications written by other developers. Thus, installation needs to be easy .. and work, despite complications like mod_rewrite or use of PATH_INFO.

The current consensus leans toward splitting this functionality (analyzing $_SERVER and normalizing the "base" URL / file path) into a new class, Zend_Http_Request. If we have Zend_Environment deployed, it might facilitate collection of environmental data (e.g. $_SERVER) to aid in testing a wide variety of deployment environments. In fact, we probably could ask everyone to voluntarily submit the "dump" from Zend_Environment to help provide a large suite of test data. See the new proposal here: http://framework.zend.com/wiki/x/JgM

The ZF will have a Zend_Config ini config file. Some details in this ini file might be configured automagically, drawing upon some of the test results from Zend_Environment, and other checks/tests, such as whether or not $_SERVER['PATH_INFO'] works.

$_SERVER[] variables that might help: - PHP_SELF - SCRIPT_FILENAME - SCRIPT_NAME - REQUEST_URI

There are other variables (e.g. environment), but the ones in $_SERVER *ought* to be the "normalized" values as created by code inside PHP itself (in the SAPI). We may find that we need a long list of use cases and must test for many in order to normalize the data we need and make things work "out of the box".

Also, we plan to have a Zend Framework "INI" file using Zend_Config. Thus, the computational resources required to test and determine the correct rewrite base won't be a concern for ZF 1.0, since the computation need not be performed on every execution.