From: merlin at merlinsbox dot net
Operating system: linux, unix
PHP version: 5.3.1
PHP Bug Type: Other web server
Bug description: FastCGI Responder's accept_path_info behavior needs to be
optional
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.
--
Edit bug report at http://bugs.php.net/?id=50852&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50852&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50852&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50852&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50852&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50852&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50852&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50852&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50852&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50852&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50852&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50852&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50852&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50852&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50852&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50852&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=50852&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50852&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50852&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50852&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50852&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50852&r=mysqlcfg
