Bug #55208 [Opn->Fbk]: setting correct SCRIPT_NAME vs PHP_SELF is impossible in certain circumstances

Edit report at https://bugs.php.net/bug.php?id=55208&edit=1 ID: 55208 Updated by: cmb@php.net Reported by: loco at andrews dot lv Summary: setting correct SCRIPT_NAME vs PHP_SELF is impossible in certain circumstances -Status: Open +Status: Feedback Type: Bug Package: FPM related Operating System: Gentoo Linux (2.6.39-gentoo-r3) PHP Version: 5.3.6 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: > Should presumable be fixed with > https://bugs.php.net/bug.php?id=65641 Is it? 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