ID: 50837 Updated by: [email protected] Reported By: info at karlblessing dot com Status: Bogus Bug Type: CGI related Operating System: Debian 5.0 x86_64 GNU/Linux PHP Version: 5.2.12 New Comment:
PHP walks back through the script_filename it is passed and tries to find the script to execute. Once again, it is the web server's job to figure out that a URI doesn't exist. PHP doesn't serve up 404s under any circumstances. If all your web server is doing is a simple regex to determine whether something should be executed or not, then your web server is broken. Previous Comments: ------------------------------------------------------------------------ [2010-01-25 22:41:21] info at karlblessing dot com But PHP is second guessing, it was sent "/test.txt/1.php" as the original script_filename, that file doesn't exist on the system, so how does it execute the code if 1.php does not exist? As a result it was the parser that move down to the test.txt. Again, note the original script_filename sent to the parser. ------------------------------------------------------------------------ [2010-01-25 22:38:52] [email protected] It still doesn't matter. By the time the request makes it to PHP, PHP is going to execute. I bet you can't reproduce this on a properly configured Apache server that correctly finds the script and the pathinfo. Note that in your output your ORIG_PATH_INFO is empty, which is incorrect. If your URI is /test.txt/1.php and /test.txt exists, then "/1.php" is the PATH_INFO. Obviously your server doesn't seem to understand that and determines the URI should be executed by PHP. The executable part of your URI is /test.txt and it isn't PHP's job to second-guess that. ------------------------------------------------------------------------ [2010-01-25 22:35:36] info at karlblessing dot com Regarding the webserver, Nginx matches up php via regex, as per the wiki provided http://wiki.nginx.org/PHPFcgiExample#Connecting_Nginx_to_the_running_F astCGI_Process location ~ \.php$ { ... } would match up to a php file request. It is my opinion that the PHP parser should take script_filename litterally. That is to say script_filename = /test.txt/1.php path_info = no value shouldn't execute but script_filename = /test.txt path_info = /1.php should execute, if the webserver indeed sent it those values. In my case it only sent /test.txt/1.php , which should not have worked because that filename does not exist on the system. ------------------------------------------------------------------------ [2010-01-25 22:32:36] info at karlblessing dot com 1.php was from a previous test when I typed /1.php after test.txt, if you type /fake.php after test.txt it'll show fake.txt, just like how I don't own domain.com, you apparently can't go back and edit the original. ------------------------------------------------------------------------ [2010-01-25 22:30:10] [email protected] Well, first, there is no fake.php in your output there. So I don't know about your "evidently" since your evidence doesn't match at all. And second, PHP doesn't set SCRIPT_FILENAME, your web server does. So your web server determined that the script to execute was "/opt/html/domain/test.txt" evidently as per your own evidence. So PHP executed that script. I am not sure why that is surprising to you. Why is your web server telling PHP to run test.txt? PHP doesn't check the filetype. It runs what it is told to run. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50837 -- Edit this bug report at http://bugs.php.net/?id=50837&edit=1
