Hi,
I had prepared a fix for bug #23610 (http://bugs.php.net/23610)
that complains PATH_TRANSLATED is not populated under Apache2 SAPI,
but I ended up reverting it as Shane told me that the patch was
technically wrong while that variable is designed to be set to
SCRIPT_FILENAME if it's absent under Apache1 SAPI.
After a short discussion on this issue with Ilia at php.bugs, I'm now
under the impression that the patch should be revisited, as the issue is
originally focused as a great BC break and there's no specification that
instructs us to make all SAPI act as if it was using CGI.
What do you think of this?
The patch was http://cvs.php.net/diff.php/php4/sapi/apache2handler/sapi_apache2.c?r1=1.1.2.9&r2=1.1.2.10&ty=h
(for unified diff)
http://cvs.php.net/diff.php/php4/sapi/apache2handler/sapi_apache2.c?r1=1.1.2.9&r2=1.1.2.10&ty=u
Moriyoshi
Hi,
I had prepared a fix for bug #23610 (http://bugs.php.net/23610)
that complains PATH_TRANSLATED is not populated under Apache2 SAPI,
but I ended up reverting it as Shane told me that the patch was
technically wrong while that variable is designed to be set to
SCRIPT_FILENAME if it's absent under Apache1 SAPI.
+1
I think PATH_TRANSLATED is a fairly important variable to have and by having
it avaliable it makes Apache 1 > Apache 2 that much migration easier. IMO the
Apache 2 sapi should work the same way as Apache 1 sapi does.
Ilia
Ilia A. wrote:
Hi,
I had prepared a fix for bug #23610 (http://bugs.php.net/23610)
that complains PATH_TRANSLATED is not populated under Apache2 SAPI,
but I ended up reverting it as Shane told me that the patch was
technically wrong while that variable is designed to be set to
SCRIPT_FILENAME if it's absent under Apache1 SAPI.+1
I think PATH_TRANSLATED is a fairly important variable to have and by having
it avaliable it makes Apache 1 > Apache 2 that much migration easier. IMO the
Apache 2 sapi should work the same way as Apache 1 sapi does.Ilia
-1
It is inconsistent to set PATH_TRANSLATED to different things depending
on whether real PATH_INFO is used or not. This inconsistency makes
PATH_TRANSLATED unreliable. Apache is doing the right thing, why should
PHP go and mess that up?
For example (with the patch in question being used):
DOCUMENT_ROOT=/web
URL: http://host/path/to/script.php
PATH_TRANSLATED=/web/path/to/script.php
SCRIPT_FILENAME=/web/path/to/script.php
URL: http://host/path/to/script.php/path_info
PATH_TRANSLATED=/web/path/to/path_info
SCRIPT_FILENAME=/web/path/to/script.php
And without the patch:
URL: http://host/path/to/script.php
PATH_TRANSLATED=
SCRIPT_FILENAME=/web/path/to/script.php
URL: http://host/path/to/script.php/path_info
PATH_TRANSLATED=/web/path/to/path_info
SCRIPT_FILENAME=/web/path/to/script.php
SAPI modules should strive to be consistent with these variables, and
should provide them as specified and documented (not talking about PHP
documentation is which wrong in this regard), even if the server in
question doesn't do it correctly either.
Being consistent in this regard provides better capability to write
portable scripts that can work under different environments, and
provides the ability to properly utilize url mechanisms as they are
designed. PHP's incorrect usage of these variables has caused a
situation where applications written against one web server to not work
on others (yes, I have run into scripts with just this problem) simply
because the spec was not correctly followed, and has caused
missinformation about the use and meaning of these variables (ie. I've
seen comments on bugs, articles, and email lists that are inconsistent
in addition to being simply incorrect).
I understand the BC issue well, and if the patch includes a way (ie.
horrid ini setting) to make the module set the variables correctly I'd
be fine with it. Default for PHP 4 can be the broken PATH_TRANSLATED,
but PHP 5 should simply use the correct behaviour.
Shane
It is inconsistent to set PATH_TRANSLATED to different things depending
on whether real PATH_INFO is used or not. This inconsistency makes
PATH_TRANSLATED unreliable. Apache is doing the right thing, why should
PHP go and mess that up?
A valid point, however we have a big Apache 1 userbase who are used to the old
behavior. Why must we alienate them and break their scripts if they are
forced to switch to Apache 2? There is little or nothing that we lose from
maintaining the old behavior, even though it may not entirely correct.
Ilia
Ilia A. wrote:
It is inconsistent to set PATH_TRANSLATED to different things depending
on whether real PATH_INFO is used or not. This inconsistency makes
PATH_TRANSLATED unreliable. Apache is doing the right thing, why should
PHP go and mess that up?A valid point, however we have a big Apache 1 userbase who are used to the old
behavior. Why must we alienate them and break their scripts if they are
forced to switch to Apache 2? There is little or nothing that we lose from
maintaining the old behavior, even though it may not entirely correct.Ilia
Well, it matters little if you do not use PATH_INFO, it can matter a lot
if you do, but it still matters irregardless. You could also consider
it a possible hole if your script depends on PATH_TRANSLATED being the
same as SCRIPT_FILENAME, and you use it as such. A contrived example
would be using the dirname of PATH_TRANLSATED to include some script.
Just adding path_info to the url would break their script.
It also matters a lot from understanding the protocol and documentation
standpoints and reducing WTF.
I'm not saying don't put it in, I'm saying make it configurable, and for
PHP5, make the 'correct' way the default configuration. This way people
can still run scripts that depend on the old behaviour, but we can start
to ween people away from incorrect usage of this stuff.
Shane
I'm not saying don't put it in, I'm saying make it configurable, and for
PHP5, make the 'correct' way the default configuration. This way people
can still run scripts that depend on the old behaviour, but we can start
to ween people away from incorrect usage of this stuff.
Sounds good to me.
- Sascha