ID: 50852
Comment by: merlin at merlinsbox dot net
Reported By: merlin at merlinsbox dot net
Status: Feedback
Bug Type: CGI related
Operating System: linux, unix
PHP Version: 5.*, 6
New Comment:
Yes, thanks jani; 'cgi.fix_pathinfo = 0' is the behavior we're looking
for, apparently; however, I am confused at least by the explanation for
it because in no case whatsoever did I pass anything except
SCRIPT_FILENAME to PHP.
Two days in ##php, a patch, and two bug reports before someone knew.
Thanks again!
Curious if this patch provided above has any merit on its own. I
imagine it accomplishes the same thing as cgi.fix_pathinfo in another
place in the code (or the author would have said OH here is the
setting). Perhaps it is in a better place (or perhaps a worse one!).
Previous Comments:
------------------------------------------------------------------------
[2010-01-28 08:58:19] j...@php.net
Wouldn't setting cgi.fix_pathinfo = 0 do the same thing?
------------------------------------------------------------------------
[2010-01-27 02:13:35] merlin at merlinsbox dot net
Yes, I realize at the top I only mention 5.2.12, and that I posted this
in 5.3.1 -- I also linked to the patch for 5.3.1 (and there is a patch
for 5.2.12 in that directory as well). This is an issue in both
versions and will continue to be in future versions, unless the patch is
accepted.
Apologies for overlooking that first sentence.
------------------------------------------------------------------------
[2010-01-27 02:05:53] merlin at merlinsbox dot net
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 this bug report at http://bugs.php.net/?id=50852&edit=1
