Edit report at https://bugs.php.net/bug.php?id=55208&edit=1
ID: 55208
Updated by: kalle@php.net
Reported by: loco at andrews dot lv
Summary: setting correct SCRIPT_NAME vs PHP_SELF is
impossible in certain circumstances
-Status: Assigned
+Status: Open
Type: Bug
Package: FPM related
Operating System: Gentoo Linux (2.6.39-gentoo-r3)
PHP Version: 5.3.6
-Assigned To: fat
+Assigned To:
Block user comment: N
Private report: N
Previous Comments:
------------------------------------------------------------------------
[2016-06-04 01:00:43] anrdaemon at yandex dot ru
Should presumable be fixed with https://bugs.php.net/bug.php?id=65641
------------------------------------------------------------------------
[2014-01-07 11:04:07] JBlond at gmail dot com
with my last WAMP installations I had to use this getting it working
in apache
FcgidFixPathinfo 0
and in php.ini
cgi.fix_pathinfo = 1
------------------------------------------------------------------------
[2011-07-17 11:57:39] loco at andrews dot lv
>If we look into the code of differents SAPIs, here what's done:
>
>apache2handler: PHP_SELF is set REQUEST_URI given by apache.
>So it should be /test.php/foo.bar
...unless the URI never contains .php but instead is handled by PHP interpreter
via Apache rewrite rule:
RewriteRule ^(.*)$ /index.php$1 [L]
And in this case, when accessing URL /foo/bar, both PHP_SELF and SCRIPT_NAME are
set to "/foo/bar". This is exactly what I want to achieve in cgi/fpm SAPI in
nginx, but cannot find any way so far. Best I could come up with is not to
submit SCRIPT_NAME and submit PHP_SELF equal to $uri.
Andrejs
------------------------------------------------------------------------
[2011-07-17 11:42:28] loco at andrews dot lv
Jerome, thanks for looking into this issue.
The main trouble is that sometimes, even for FCGI/FPM SAPI both SCRIPT_NAME and
PHP_SELF must refer to the original URI, and *NOT* to SCRIPT_FILENAME! This
behaviour is desired, for example, in order to support older eZPublish or vTiger
CRM code that relies on PHP_SELF and assumes it contains the original URI, not
the SCRIPT_FILENAME, which would be /index.php.
So, I thought it would be as simple as this:
fastcgi_param PHP_SELF $uri;
fastcgi_param SCRIPT_NAME $uri;
Apparently, it isn't, and PHP-FPM adjusts these variables by itself, even though
they are submitted via server environment. I've been experiencing situations
when PHP_SELF would contain a double path, or that PHP_SELF would contain
/index.php/, but all I need both to contain is the original URI without
arguments.
In addition, when cgi.fix_pathinfo is set to 0, I am not able to access any PHP
scripts as I get "No input file specified" response in the browser.
Please additionally notice that your suggestion with fastgi_split_path_info
doesn't work, no matter which value cgi.fix_pathinfo is set to, as
PATH_INFO/PATH_TRANSLATED remain empty.
------------------------------------------------------------------------
[2011-07-17 10:55:31] fat@php.net
As described in http://php.net/manual/en/reserved.variables.server.php
'PHP_SELF': The filename of the currently executing script, relative to the document root.
For instance, $_SERVER['PHP_SELF'] in a script at
the address http://example.com/test.php/foo.bar
would be /test.php/foo.bar
whereas
'SCRIPT_NAME': Contains the current script's path.(without further details).
If we look into the code of differents SAPIs, here what's done:
apache2handler: PHP_SELF is set REQUEST_URI given by apache. So it should be /test.php/foo.bar
cgi/fpm (the code for this part is the same):
PHP_SELF is set to REQUEST_URI if cgi.fix_pathinfo is 0.
PHP_SELF is set to SCRIPT_NAME if cgi.fix_pathinfo is 1.
this cgi.fix_pathinfo is a real mess (see https://bugs.php.net/bug.php?id=51983).
I don't really know what to think about all this right now ...
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=55208
--
Edit this bug report at https://bugs.php.net/bug.php?id=55208&edit=1