Description:
------------
I setup PHP 5.2.12 and started 5 fastcgi processes on nginx with a basic location directive dispatching all URIs ending with the PHP extension to PHP's fastcgi responder daemon. I also configured it to receive SCRIPT_FILENAME (required by PHP) as a concatenation of $document_root and the matched URI (which must end in '.php') and PATH_INFO as the requested URI.  No other fastcgi parameters were used.  I created a file in the document root thusly: `echo "<pre><?php var_dump($_SERVER); ?></pre>" > test.txt`.  I requested /test.txt and was presented with the source code.  Next, I requested /test.txt/.php and the code executed, resulting in the following output (truncated for relevence):

  ["SCRIPT_FILENAME"]=>
  string(31) "/path/to/document_root/test.txt"
  ["ORIG_SCRIPT_FILENAME"]=>
  string(37) "/path/to/document_root/test.txt/1.php"

Reproduce code:
---------------
# NginX configuration for PHP extensions
location ~ \.php$ {
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_pass php-responder; # php- replaced with python- for python
}

# PHP code and request
echo "<pre><?php var_dump($_SERVER); ?></pre>" > test.txt && fetch http://localhost/test.txt/.php

# Python WSGI app
def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['<pre>', '\n'.join(['%s: %s' % (k, v) for k,v in environ.items()]), '</pre>']


Expected result:
----------------
I expected PHP to return "no input file specified" such as when I request /1.php on the server (which does not exist).  I did not expect PHP to travel up the path looking for PHP files to execute, and I would like to disable this feature.

Please consider accepting the patch by Joey Smith located at: http://patch.joeysmith.com/acceptpathinfo-5.3.1.patch (and other versions in the root).  This patch allows me to turn off this feature but keeps the current behavior as default, which is surely best for all parties.  The best part is the patch is small, trivial even, so there should be little to worry about in bringing it in.

PHP's accept_path_info behavior makes perfect sense for CGI, where it is implicit that there is a direct relationship between a URI location and a file.  PHP now is a FastCGI responder, and I hear doesn't even support plain CGI any longer.  FastCGI is not a direct analogue of CGI, though it may emulate it in the responder role.  At any rate, though FastCGI extends CGI, and some FastCGI apps *can* run in CGI, FastCGI is not being used these days as a direct analogue of CGI by other languages.  SCRIPT_FILENAME is a PHP-specific FastCGI parameter not mentioned anywhere in the FastCGI specification (because it is not required that a file be executed by a responder).  Furthermore, while I understand that FastCGI and Apache have some history, many other servers have also implemented FastCGI support and they do not necessarily make the same assumptions Apache does.  Relying on the webserver to stat URIs in a CGI environment makes perfect sense; however, if your webserver doesn't support CGI at all, but only FastCGI, it makes none.  

To illustrate this point, I created a simple python fastcgi responder using flup and the hello world WSGI application modified to output the environment (provided below).  Then, instead of passing php extensions to PHP's fastcgi, I passed it to my python application along with SCRIPT_FILENAME as before.  My python application successfully returns to me the unchanged SCRIPT_FILENAME from its environment, because neither my webserver nor my responder make any assumptions about URLs corresponding to files.  



Actual result:
--------------
To sum up, forcing my webserver to treat PHP's FastCGI responder differently from other FastCGI responders is distasteful, and whether you agree with my needs or not, there is an already completed patch which maintains backwards compatibility that I and many other people will be very thankful for.  PHP isn't going anywhere and neither is Nginx (growing quite a bit, in fact!).  Let's work together to make things safe and efficient for all.  Refusing this patch because of a monoculture bias to Apache doesn't make things safer for anyone.