php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50852 FastCGI Responder's accept_path_info behavior needs to be optional
Submitted: 2010-01-27 02:05 UTC Modified: 2010-01-29 01:14 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: merlin at merlinsbox dot net Assigned:
Status: Closed Package: CGI/CLI related
PHP Version: 5.*, 6 OS: linux, unix
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: merlin at merlinsbox dot net
New email:
PHP Version: OS:

 

 [2010-01-27 02:05 UTC] 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.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-01-27 02:13 UTC] 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-28 08:58 UTC] jani@php.net
Wouldn't setting cgi.fix_pathinfo = 0 do the same thing? 
 [2010-01-28 22:29 UTC] merlin at merlinsbox dot net
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!).
 [2010-01-28 22:47 UTC] merlin at merlinsbox dot net
Feature exists, no one, not even Rasmus, knew, except jani.  Jani for President.
 [2010-01-29 01:14 UTC] joey@php.net
For the record, I saw cgi.fix_pathinfo but didn't really understand
the documentation on it - probably my fault. The patch was thrown
together mainly as a personal exercise in understanding the problem
these folks were reporting - I see no reason it should be accepted
into the mainline.
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC