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?id=40102

If you place your RewriteRules under <Directory> or in .htaccess everything works. But if you place it directly under <VirtualHost> 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.

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.

http://www.foo.com/index.php/something/goes/here

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".