|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2018-05-05 18:09 UTC] requinix@php.net
-Status: Open
+Status: Feedback
-Type: Feature/Change Request
+Type: Bug
-Package: Feature/Change Request
+Package: Apache related
[2018-05-05 18:09 UTC] requinix@php.net
[2018-06-24 04:22 UTC] php-bugs at lists dot php dot net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Dec 13 13:00:01 2025 UTC |
Description: ------------ The CGI 1.1 specification specifies that a request for http://example.com/test/test.php/argument where test.php is a PHP script Would define PHP_INFO: /argument PATH_TRANSLATED: /www/htdocs/argument (asuming that /www/htdocs is the on the document root) Apache correctly set these variables, and PHP lists then in the _SERVER variable, and passes them to the test.php script. To my surprise, PHP not only executes test.php, but aparently also does an Apache subrequest for /argument. This request is not displayed in the access log. However, the subrequest can be seen in the error log if / is disallowed ("deny from all" in the .htaccess file), and allowed in /test/ ("allow from all in the /test/.htacess file). Reproduce code: --------------- See above. Files in the document root, with content: /.htaccess: Order allow,deny /test/.htaccess: allow from all /test/test.php: <p>PHP file</p> /test/test.txt: <p>Text file</p> Expected result: ---------------- I would expect that a call to /test/test.php would display the contents of the file, pass the CGI variables, and just do that, and nothing more. Actual result: -------------- A request to /test/test.php/argument displays the files content "<p>PHP file</p>", as expected. However, the Apache error log also shows "client denied by server configuration: /www/htdocs/argument, referer: http://www.example.com/test/test.php/argument" I did not expect this subrequest; it does not seem necessary to make the request. In fact, if the file does exists, and is accessible, the output of the request does not change. So the subrequest seems spurious to me. Feature request: I recommend to remove the Apache subrequest (or whatever it exactly is). If the subrequest has a purpose, I'm curious to hear the reason, and I recommend instead to add an option to disable it. Note that the --disable-path-info-check configuration parameter is not what I want: that completely disables the requests with PATH_INFO. I just don't want PHP or Apache to make a request to it. Regression notes: A request to /test/test.txt/argument gives and error "404 No such file "/test/test.txt/argument". No other error is logged. This indicated that indeed the fact that PHP makes the Apache subrequest, and not Apache itself. I found this behaviour when running MediaWiki, which makes use of these kind of URL's in the form of /wiki/index.php/Article. I'm running Apache 2.0.54