ID: 24502 User updated by: gwang at litespeedtech dot com Reported By: gwang at litespeedtech dot com -Status: No Feedback +Status: Open Bug Type: CGI related Operating System: Linux -PHP Version: 4.3.3 +PHP Version: 4.3.2 Assigned To: shane New Comment:
Thank you for the response. Here is the result. Testing url /phpinfo.php/path/info?a=b is used, when set cgi.fix_pathinfo=0, same result (0 is the default according to the comments in the ini file), "no input file" is returned. set cgi.fix_pathinfo=1, the php information page is returned, but _SERVER["PATH_INFO"] and _SERVER["PATH_TRANSLATED"] contain no value and the vlaue of _SERVER["ORIG_XXXX"] environment variables are all correct. I don't think set cgi.fix_pathinfo=1 is the right fix for this bug. All correct values are provided in the first place, why waste CPU cycles to try to guess them from other sources? I think the cleanest and probably the easiest fix is to provide a configuration directive to skip all the reverse hacking code. best regards, LiteSpeed Team Previous Comments: ------------------------------------------------------------------------ [2003-09-29 05:58:48] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. ------------------------------------------------------------------------ [2003-09-24 12:03:07] [EMAIL PROTECTED] Check php.ini for cgi.fix_pathinfo and try setting it to 1 or 0. ------------------------------------------------------------------------ [2003-08-25 16:28:02] gwang at litespeedtech dot com This has not been completely fixed in 4.3.3. When there is no PATH_INFO, it works fine. When PATH_INFO is populated, it breaks. Try something like /phpinfo.php/path/info?a=b The reason it breaks is PATH_TRANSLATED is used as the path to the PHP script file instead of SCRIPT_FILENAME when PAHT_INFO is popluated. As our LiteSpeed web server follows the CGI specification, all the code controled by macro #if !DISCARD_PATH and #if ENABLE_PATHINFO_CHECK are not necessory. If PHP is configured with following options, ./configure --enable-fastcgi --enable-discard-path --disable-path-info-check then the testing URL /phpinfo.php/path/info?a=b works just fine except the PHP and Zend logos are missing due to the wrong value of PHP_SELF. According to the comments in the code that the way PHP_SELF populated is to provide backward compatibility for version before 4.3. My question is, is this another reverse hacking for web server that does not follow CGI spec, like Apache? By doing so, PHP_SELF is happen to be the right value for them? If so, those code should be moved inside the section controled by macro ENABLE_PATHINFO_CHECK or !DISCARD_PATH. I think it is better to seperate the reserve hacking code for Apache's fast CGI interface from the others as it is the only odd guy. The code could be much cleaner. Just some suggestions. Sincerely, LiteSpeed Team . ------------------------------------------------------------------------ [2003-07-04 18:04:00] gwang at litespeedtech dot com Also, when I test it with phpinfo(), if the PATH_INFO is not empty, PHP_SELF is set to PATH_INFO instead of SCRIPT_NAME, then the PHP and Zend logos are missing. ------------------------------------------------------------------------ [2003-07-04 16:53:44] gwang at litespeedtech dot com Description: ------------ Fast CGI interface is broken in both 4.3.2 4.3.3rc1 and the most recent snap shot for web server with Fast CGI implementation that follows CGI specification. Our LiteSpeed web server (at http://www.litespeedtech.com ) supports PHP through the Fast CGI interface (faster than Apache's mod_php). Our Fast CGI implementation follows the CGI specification and set environment variables exactly as what Apache's CGI does. It set SCRIPT_FILENAME=/docroot/info.php and works fine with 4.3.1, but the interface is broken since 4.3.2. Our test shows that SG(request_info).path_translated is not populated with the value of SCRIPT_FILENAME but is NULL. Further study shows that the root cause is at cgi-main.c:812 in release 4.3.2 > script_path_translated=env_path_translated; set script_path_translated to NULL or whatever the value of PATH_TRANSLATED. If we take that line out, every thing works fine. We can use --enable-discard-path to avoid it but it is forbidden in README.FastCGI (We don't know why based on our reading of the source code). I think one possilbe fix is to avoid that line of code for FastCGI, but may need to add some code for Apache's mod_fastcgi. Or change the document, say: --enable-discard-path should be used for web server follows CGI Specs. Sincerely, LiteSpeed Team ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=24502&edit=1
