Edit report at http://bugs.php.net/bug.php?id=51983&edit=1
ID: 51983
User updated by: konstantin at symbi dot org
Reported by: konstantin at symbi dot org
Summary: [fpm sapi] pm.status_path not working when
cgi.fix_pathinfo=1
Status: Assigned
Type: Bug
Package: FPM related
Operating System: Any
PHP Version: 5.3SVN-2010-06-03 (snap)
Assigned To: fat
New Comment:
FPM sapi implements remote fastcgi only (also known as "external
FastCGI").
So it is limited to web servers which support it.
I have tested Nginx, Lighttpd, and Apache mod_fastcgi.
For other webservers listed, are there ones which of them support remote
fastcgi? At least I am sure that IIS does not (even with its latest
fastcgi
implementations, I've asked this question on IIS FastCGI forums). As far
as I
know, thttpd does not, too.
Previous Comments:
------------------------------------------------------------------------
[2010-06-04 08:59:23] f...@php.net
I'm asking about Apache, to be certain not to ban some webservers from
using
FPM.
According to http://www.fastcgi.com/drupal/node/3, we have to make sure
that FPM
is compliant with all of the following webservers:
Apache
Microsoft IIS
Microsoft IIS (second generation)
SunOne
Lighttpd
Premium thttpd http
MyServer
Pi3Web
WebSTAR (Mac OS)
Nginx
Cherokee
------------------------------------------------------------------------
[2010-06-04 08:52:49] konstantin at symbi dot org
99% of fpm installations are with nginx or lighty, using fpm sapi with
non-FSM
webservers is at least very strange. But I have just checked it with
Apache+mod_fastcgi in a simplest configuration:
DocumentRoot "/var/www"
FastCgiExternalServer /var/www -socket /tmp/php-fpm.sock
<Directory /var/www>
Options FollowSymLinks +ExecCGI
AllowOverride All
Order Allow,Deny
Allow from all
</Directory>
and it works OK.
The patch contains comments in the top of the new init_request_info()
implementation. It describes why fastcgi parameters are mapped to the
script
filename in this way, and it was chosen after examining CGI specs,
typical fpm
configurations, and common sense.
BTW, those webservers like old IIS versions with buggy cgi
implementations which
required that awkward way of guessing what they meant, for which the
original
implementation of init_request_info() was designed, do not support
remote
FastCGI at all.
------------------------------------------------------------------------
[2010-06-04 08:25:19] f...@php.net
Have you tried your patch with other webservers than nginx and lighttpd
?
------------------------------------------------------------------------
[2010-06-04 06:32:12] sergo_s at bk dot ru
I met problem "No input file specified" in the configuration of lighttpd
1.4.26 + php-5.3.2 + fastcgi/php-fpm when requesting addresses like
index.php/myMethod/ (kohanaframework based site). I found that
$_SERVER[PATH_INFO] is NULL.
(More about my problem in this post:
http://phpclub.ru/talk/showthread.php?s=&postid=902382 (russian))
This patch solved the problem. Thanks.
------------------------------------------------------------------------
[2010-06-03 04:42:33] konstantin at symbi dot org
Description:
------------
FPM status does not work when cgi.fix_pathinfo = 1, with the default
nginx
configuration for php (default fastcgi_params + SCRIPT_FILENAME added).
The problems is that in fpm_main.c, here:
if (!strcasecmp(SG(request_info).request_method, "GET") &&
fpm_status_handle_status(SG(request_info).request_uri, ...
SG(request_info).request_uri is sometimes NULL depending on the
trickiest things
which happen when cgi.fix_pathinfo = 1.
I have examined the code of init_request_info() which runs when
cgi.fix_pathinfo
= 1, and I found out that this part of code is legacy part from the CGI
SAPI, it
is was designed to fix problems with a lots of broken CGI
implementations. It
was reasonable for CGI to get the things working independent on speed,
but the
'bruteforce' approach used is not too good for FPM SAPI which is
commonly used
on high-bandwidth sites.
More, PHP introduces non-standard "SCRIPT_FILENAME" fastcgi env; it is
not hard
to add it to configuration of flexible servers like nginx (by using
"fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name" in
its
configuration), but it can cause problems with such servers as lighttpd
where
all the fastcgi parameters are hardcoded (I've seen people on forums
complaining
thay get 'no input file' with nginx+fpm and they found no way to fix
it).
So, I have found the fix_pathinfo part is written in a hard to
understand and
difficult to fix way, and that is is really not required for FPM SAPI,
and that
it slows it down. System administrators who configure FSM webservers and
use FPM
sapi are usually experianced and for them it would be preferable to have
strict
and simple logic rather then some magic which can potentially slow
things down a
lot. So i have rewritten init_request_info(), the the suggested patch is
attached.
It logic of detection script_filename is much simpler:
if SCRIPT_FILENAME is defined, use it,
else if both DOCUMENT_ROOT and SCRIPT_NAME are defined, concat them and
use
(should fix all the problems with lighty etc);
else if PATH_TRALSLATED is defined, use it as script_filename;
else we do not know the script_filename.
And, of course, it fixes the problem with pm.status_path I started with.
Test script:
---------------
N/A
Expected result:
----------------
N/A
Actual result:
--------------
N/A
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=51983&edit=1
