Bug #51983 [Asn]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1

Edit report at http://bugs.php.net/bug.php?id=51983&edit=1 ID: 51983 Updated by: tony2001@php.net 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: Jerome, I agree that we should drop this fix_pathinfo stuff - it makes no sense to adopt all the freaky things from CGI API. The patch requires some extensive testing, though, that's clear. But I don't think we should keep in mind of all the web-servers you mentioned. Apache, nginx & lightty are my biggest concern, others can be safely dropped (or assumed working). You can forget about IIS anyway, FPM doesn't support Windows. Previous Comments: ------------------------------------------------------------------------ [2010-06-04 09:07:10] konstantin at symbi dot org And of course I never say we should do anything with the CGI/FCGI sapi. I am sure its implementation must not be chanhed 'cause it was tested with many webservers during years. I am speaking only about FPM sapi which is much more specific. ------------------------------------------------------------------------ [2010-06-04 09:04:54] konstantin at symbi dot org 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. ------------------------------------------------------------------------ [2010-06-04 08:59:23] fat@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] fat@php.net Have you tried your patch with other webservers than nginx and lighttpd ? ------------------------------------------------------------------------ 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 http://bugs.php.net/bug.php?id=51983 -- Edit this bug report at http://bugs.php.net/bug.php?id=51983&edit=1