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

From: Operating system: Any PHP version: 5.3SVN-2010-06-03 (snap) Package: CGI related Bug Type: Bug Bug description:[fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1 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 bug report at http://bugs.php.net/bug.php?id=51983&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51983&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51983&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51983&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51983&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51983&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51983&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51983&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51983&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51983&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51983&r=support Expected behavior: http://bugs.php.net/fix.php?id=51983&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51983&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51983&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51983&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51983&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=51983&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51983&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51983&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51983&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51983&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51983&r=mysqlcfg