ID: 24502
User updated by: gwang at litespeedtech dot com
Reported By: gwang at litespeedtech dot com
Status: Bogus
Bug Type: CGI related
Operating System: Linux
PHP Version: 4.3.4 dev
Assigned To: shane
New Comment:
I did read the comments, my understanding is that PATH_TRANSLATED will
be fixed to conform to the CGI spec if it does not. It is great for
those guys who do not follow CGI spec.
The problem is when CGI spec has been followed, PATH_TRANSLATED is the
translated PATH_INFO, SCRIPT_FILENAME is the path to the PHP script,
enabling fix_pathinfo will clear PATH_INFO and PATH_TRANSLATED (set
them to NULL), it will be a disaster for CGI script needs PATH_INFO.
fix_pathinfo and discar_path is not necessary at all when the spec has
been followed.
If you want, try it with our web server, it only take about 5 minutes
to install, PHP (4.3.1) works out of box without any additional
configuration. Just replace lsws/fcgi-bin/php with new PHP executable.
Thanks,
Litespeed
Previous Comments:
------------------------------------------------------------------------
[2003-09-29 21:48:07] [EMAIL PROTECTED]
Read the note above the cgi.fix_pathinfo in php.ini-dist (found in the
release tarball). There is no bug.
------------------------------------------------------------------------
[2003-09-29 16:06:07] gwang at litespeedtech dot com
BTW: I tested the latest stable snapshot.
------------------------------------------------------------------------
[2003-09-29 16:03:36] gwang at litespeedtech dot com
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
------------------------------------------------------------------------
[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
.
------------------------------------------------------------------------
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/24502
--
Edit this bug report at http://bugs.php.net/?id=24502&edit=1
