# Apache2 SAPI behaviour regarding PATH_TRANSLATED - Thread: https://externals.io/message/1639 - Original archive: https://news-web.php.net/php.internals/1639 - Started by Moriyoshi Koizumi on 2003-05-17T20:47:28+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #1639 — Moriyoshi Koizumi — 2003-05-17T20:47:28+00:00 URL: https://externals.io/message/1639#1639 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 --- ## #1640 — Ilia A. — 2003-05-17T21:01:49+00:00 URL: https://externals.io/message/1639#1640 · In reply to: #1639 > 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 --- ## #1642 — Shane Caraveo — 2003-05-17T21:26:53+00:00 URL: https://externals.io/message/1639#1642 · In reply to: #1640 Ilia A. wrote: > > > > […] > > > +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 --- ## #1646 — Ilia A. — 2003-05-18T00:47:29+00:00 URL: https://externals.io/message/1639#1646 · In reply to: #1642 > 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 --- ## #1647 — Shane Caraveo — 2003-05-18T00:59:10+00:00 URL: https://externals.io/message/1639#1647 · In reply to: #1646 Ilia A. wrote: > > > > […] > > > 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 --- ## #1654 — Sascha Schumann — 2003-05-18T11:01:29+00:00 URL: https://externals.io/message/1639#1654 · In reply to: #1647 > 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