Edit report at https://bugs.php.net/bug.php?id=51983&edit=1
ID: 51983
Comment by: f...@php.net
Reported by: konstantin at symbi dot org
Summary: [fpm sapi] pm.status_path not working when
cgi.fix_pathinfo=1
Status: Analyzed
Type: Bug
Package: FPM related
Operating System: Any
PHP Version: 5.3SVN-2010-06-03 (snap)
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
> Do the issues with apache_mod_fastcgi still exist? I remember I've tested it
> with my patch and it worked well, maybe you've missed some of its settings?
Using a global mod_fastcgi configuration (where everything is sent to FPM)
returns full compliant fastcgi envars which are compatible
with the "rfc3875" mode.
Using a specific mod_fastcgi configuration (AddHandler, AddAction and Alias)
returns buggy fastcgi envars which are compatible with the
"apache_mod_fastcgi" mode.
> Personally I don't like introducing such "magic" settings which are unclear
> on
> what they do. It reminds me of that crappy "broken-scriptfilename" and "fix-
> root-scriptname" lighttpd fastcgi settings. I indeed prefer the nginx way
where
> every fastcgi variable is configured explicitly.
I hear you. I don't really mind since the "magic" settings are documented and
explain what they do. A simple explication "use
apache_mod_fastcgi is your are using mod_fastcgi using ScriptAlias,
apache_mod_proxy_fcgi if your using mod_proxy_fcgi, compliant
otherwise. If you encouters problems, you can back to backward_compatibility".
And then a more specific explication
"apache_mod_fastcgi: The SCRIPT_FILENAME is deduced using DOCUMENT_ROOT +
PATH_INFO. If fix_pathinfo is set, then a reverse search is
made on the string to find out the SCRIPT_FILENAME part and the PATH_INFO part
by testing (using stat()3) the SCRIPT_FILENAME to ensure
it exists on disk."
"apache_mod_proxy_fcgi: the SCRIPT_FILENAME is deduced using DOCUMENT_ROOT +
(PATH_INFO || SCRIPT_NAME). Auto detection is used wether
to choose PATH_INFO or SCRIPT_NAME (it depends on the proxy-fcgi-pathinfo
settings). If fix_pathinfo is set, the same treatment is done
than it's done for apache_mod_fastcgi"
"rfc3875: SCRIPT_FILENAME is deduced using DOCUMENT_ROOT + SCRIPT_NAME. No
other
actions are taken as the PATH_INFO stuff is done by
the web server"
"backward_compatibility: old code untouched. Will maybe be removed in later
major release"
> In general it's OK, but I world prefer more obvious settings with names
telling
> about real fastcgi parameters. It's the matter of taste of course.
What do you have in mind ?
Another possibility would be to set the transormation rules inside of fpm
configuration with something like:
envvar[SCRIPT_FILENAME] = "%{DOCUMENT_ROOT}%{SCRIPT_NAME}"
envvar[SCRIPT_NAME] = "%{PATH_INFO}
and keep the usage of fix_pathinfo. If set, SCRIPT_FILENAME is searched for
real
file and PATH_INFO. Otherwise nothing is done.
In the comments, for each kind of configuration (mod_fastcgi, mod_proxy_fcgi,
nginx, lighttpd) the right settings are documented.
In the case, nothing is changed, try to make autodetection based on
SERVER_SOFTWARE maybe.
But, even if it's more detailed it's maybe too complex.
> Anyway, there are two things to take into account: known clients, and
> backward
> compatibility for any possible configuration. We need to remember that this
> is
> _remote_ fastcgi, and php-fpm may run on a different machine. For instance, I
> have seen a real life nginx configuration which looked like:
>
> set $remote_php_root /path/to/remote/php/root;
> SCRIPT_FILENAME $remote_root_php/$fastcgi_script_name;
>
> and DOCUMENT_ROOT was defined to the front web server root. It is senseless,
but
> it worked: SCRIPT_FILENAME was correct, and the php code did not use
> $_SERVER['DOCUMENT_ROOT'] at all.
In all the cases we can't match all the possible solutions, especially ones for
nginx as everything can be setup as desired.
Such a configuration is marginal, I think, and a little change won't kill
anyone
(I think).
> Also, these changes really should not go to php 5.4 (or go with "compat" mode
by
> default). There already have been a BC-breaking change with
>security.limit_extensions in minor update, I believe no one wants one more.
Agree. The code will be put in 5.3, 5.4 and 5.5 but the default settings will
be
set to "rfc3875" only for 5.5 (if it's not been
released yet).
Previous Comments:
------------------------------------------------------------------------
[2013-05-13 22:57:03] konstantin at symbi dot org
Do the issues with apache_mod_fastcgi still exist? I remember I've tested it
with my patch and it worked well, maybe you've missed some of its settings?
Personally I don't like introducing such "magic" settings which are unclear on
what they do. It reminds me of that crappy "broken-scriptfilename" and "fix-
root-scriptname" lighttpd fastcgi settings. I indeed prefer the nginx way where
every fastcgi variable is configured explicitly.
In general it's OK, but I world prefer more obvious settings with names telling
about real fastcgi parameters. It's the matter of taste of course.
Anyway, there are two things to take into account: known clients, and backward
compatibility for any possible configuration. We need to remember that this is
_remote_ fastcgi, and php-fpm may run on a different machine. For instance, I
have seen a real life nginx configuration which looked like:
set $remote_php_root /path/to/remote/php/root;
SCRIPT_FILENAME $remote_root_php/$fastcgi_script_name;
and DOCUMENT_ROOT was defined to the front web server root. It is senseless,
but
it worked: SCRIPT_FILENAME was correct, and the php code did not use
$_SERVER['DOCUMENT_ROOT'] at all.
Also, these changes really should not go to php 5.4 (or go with "compat" mode
by
default). There already have been a BC-breaking change with
security.limit_extensions in minor update, I believe no one wants one more.
------------------------------------------------------------------------
[2013-05-13 21:48:16] f...@php.net
After having analyzing comments, apache behaviour, here is what I propose for
this case.
1- add a fpm configuration directive for each pool named "fastcgi_client".
Possible values are "rfc3875", "apache_mod_fastcgi",
"apache_mod_proxy_fcgi" or "backward_compatibility". Defaults to "rfc3875".
2- add a fpm configuration directive for each pool named "document_root". It
can be set to a directory. Defaults to (null).
3- add a fpm configuration directive for each pool named "always_run_script".
It can be set to a php file. Defaults to (null)
When a request is received:
/*
* Use a custom script to do some routage and other stuf
* In this case FPM does nothing but to passthrough fastcgi variables
*/
if (fpm.ini[always_run_script] is set) {
return execute_php(fpm.ini[always_run_script])
}
/*
* override DOCUMENT_ROOT if document_root is set in the FPM config
* otherwise check the DOCUMENT_ROOT sent is a valid directory
*/
if (fpm_ini[document_root] is set) {
DOCUMENT_ROOT = fpm.ini[document_root]
// no need to check if DIR exits as it's been done at conf check
} else {
if (DOCUMENT_ROOT is not set) {
return error500 "document root not set"
}
if (!is_dir(DOCUMENT_ROOT)) {
return error500 "Documentroot not found or not a directory"
}
}
if (fpm.ini[fastcgi_client] == "backward_compatibility") {
/*
* Use the same code as before (with microsoft clean up)
* Will maybe be removed in a later release.
*/
see fpm_main.c in function init_request_info()
}else if (fpm.ini[fastcgi_client] == "apache_mod_fastcgi" or
"apache_mod_proxy_fcgi") {
/*
* *** mod_fastcgi ***
*
* SCRIPT_NAME is invalid (/php5-fcgi)
* PATH_INFO is set to /test.php/more
* SCRIPT_FILENAME is invalid (/tmp/php5-fcgi)
* DOCUMENT_ROOT is set correctly
* PATH_TRANSLATED = DOCUMENT_ROOT + PATH_INFO
* REQUEST_URI is set correctly
* QUERY_STRING is set correctly
*
* ==> use DOCUMENT_ROOT + PATH_INFO
*/
/*
* *** mod_proxy_fcgi ***
*
* everything is buggy in mod_proxy_fcgi
* PATH_TRANSLATED is set only if proxy-fcgi-pathinfo is set
* PATH_TRANSLATED is set to "proxy:fcgi://host:port" + PATH_INFO
* sometimes PATH_TRANSLATED is set to "proxy:fcgi://host:port" + PATH_INFO*2
* --> we can rely on PATH_TRANSLATED no matter what
*
* PATH_INFO is set only if proxy-fcgi-pathinfo is set
* PATH_INFO is set to /test.php/more
* SCRIPT_NAME is empty if proxy-fcgi-pathinfo is set
* SCRIPT_NAME has the same value as PATH_INFO when proxy-fcgi-pathinfo is set
* --> we can rely on one of those value. They are the same depending on
* proxy-fcgi-pathinfo
*
* SCRIPT_FILENAME value is consistent and set to
* "proxy:fcgi://host:port" + PATH_INFO
*
* DOCUMENT_ROOT is set correctly
* QUERY_STRING is set correctly
*
* ==> we will use PATH_INFO or SCRIPT_NAME and DOCUMENT_ROOT
*/
if (fpm.ini[fastcgi_client] == "apache_mod_fastcgi") {
unset SCRIPT_NAME /* will use PATH_INFO instead */
}
/* automatic detection for mod_proxy_fcgi */
if (SCRIPT_NAME null or empty) {
SCRIPT_NAME = PATH_INFO
unset PATH_INFO
}
if (SCRIPT_NAME is empty) {
return error500("SCRIPT_NAME or PATH_INFO not set")
}
/* override PATH_TRANSLATED */
PATH_TRANSLATED = DOCUMENT_ROOT + SCRIPT_NAME
if (php.ini[fix_pathinfo] == 1) {
/*
* Try to determine SCRIPT_FILENAME and PATH_INFO from PATH_TRANSLATED
*/
For each '/' in PATH_TRANSLATED begining from the end of the string {
SCRIPT_FILENAME = path before the '/'
PATH_INFO = path after the '/' (with the '/' included)
if SCRIPT_FILENAME is a valid file {
PATH_TRANSLATED = DOCUMENT_ROOT + PATH_INFO
return execute_php(SCRIPT_FILENAME)
}
return error404 "file not found"
}
} else {
/*
* Suppose PATH_TRANSLATED is DOCUMENT_ROOT + SCRIPT_NAME
* ignore PATH_TRANSLATED and PATH_INFO
*/
SCRIPT_FILENAME = PATH_TRANSLATED
unset PATH_TRANSLATED
return execute_php(SCRIPT_FILENAME)
}
} else { /* rfc3875 */
/*
* simple as descript in RFC 3875
* let PATH_INFO and PATH_TRANSLATED to their value
* change nothing as we are supposed to be rfc compliant :-)
*/
if (SCRIPT_NAME not set) {
return error500 "SCRIPT_NAME not set"
}
SCRIPT_FILENAME = DOCUMENT_ROOT + SCRIPT_NAME
return execute_php(SCRIPT_FILENAME)
}
- "rfc3875" makes things very easy and quick for nginx, lighthttpd and other
compliant fastcgi clients. php.ini fix_pathinfo is not
used in this case.
- "apache_mod_fastcgi" and "apache_mod_proxy_fcgi" makes the code cleaner for
apache. Correct values are deducted. php.ini
fix_pathinfo is still used. If path_info URL are not used, fix_pathinfo can be
disabled to avoid doing useless and costy calls to
stats(). It would be maybe possible to use only one value "apache" and detect
which one is used. But I prefer not to to be able to
differentiate them later if need (as proxy_mod_fcgi could hopefully be updated
to fix some of its bugs)
- "backward_compatibility" for those who have older version of apache or else
which is not compatible with the previous mode.
Hopefully it won't be needed and will be removed in a later release.
what guys do you think ???
++ jerome
------------------------------------------------------------------------
[2011-10-30 21:03:58] mabi at gentoo dot org
What's the status of this? Any chance we can have that fixed for 5.4?
------------------------------------------------------------------------
[2011-07-20 09:16:43] konstantin at symbi dot org
IIS? FPM does not support Windows, and IIS does not support remote FastCGI.
Either
ISAPI or local FCGI (via the cgi-fcgi SAPI) are used togerher with IIS, there's
nothing about fpm.
For all other known webservers, both Jerome's and my proposals should work fine
AFAIK.
------------------------------------------------------------------------
[2011-07-20 09:08:14] slim at inbox dot lv
probably it is worth to have additional setting to set webserver in use and
select appropriate handling method.
Something like "web_server = compliant | apache | iis | anything"
this will simplify appending of hacks for custom implementations of fastcgi
protocol
------------------------------------------------------------------------
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=51983
--
Edit this bug report at https://bugs.php.net/bug.php?id=51983&edit=1
