Everything

php

Apache2 SAPI behaviour regarding PATH_TRANSLATED

php.internals

Moriyoshi Koizumi

23 years ago

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

Ilia A.

23 years ago

On May 17, 2003 04:47 pm, Moriyoshi Koizumi 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

Shane Caraveo

23 years ago

Ilia A. wrote:

> On May 17, 2003 04:47 pm, Moriyoshi Koizumi 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

Ilia A.

23 years ago

On May 17, 2003 05:26 pm, Shane Caraveo 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

Shane Caraveo

23 years ago

Ilia A. wrote:

> On May 17, 2003 05:26 pm, Shane Caraveo 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

Sascha Schumann

23 years ago

> 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

Moriyoshi Koizumi

23 years ago

Sascha Schumann <sascha@schumann.cx> wrote:

> > 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.

No more ini magics please. IMO we'd be better off preserving the bad-old
convention for 4.3, and just bringing the correct implementation into 5.0
with some notes.

Moriyoshi

Sascha Schumann

23 years ago

> No more ini magics please. IMO we'd be better off preserving the bad-old
> convention for 4.3, and just bringing the correct implementation into 5.0
> with some notes.

We should try to mitigate PHP's perception of being hard to
upgrade due to devastating BC issues.  Because of this,
sites frequently run 1-3 year old PHP versions with all their
bugs and holes.  As such, it is essential to provide support
for legacy applications even in new PHP releases.  Using inis
for that is a compromise between achieving that and doing the
Right Thing from the developer's perspective.

- Sascha

Moriyoshi Koizumi

23 years ago

Sascha Schumann <sascha@schumann.cx> wrote:

> > No more ini magics please. IMO we'd be better off preserving the bad-old
> > convention for 4.3, and just bringing the correct implementation into 5.0
> > with some notes.
>
>     We should try to mitigate PHP's perception of being hard to
>     upgrade due to devastating BC issues.  Because of this,
>     sites frequently run 1-3 year old PHP versions with all their
>     bugs and holes.  As such, it is essential to provide support
>     for legacy applications even in new PHP releases.  Using inis
>     for that is a compromise between achieving that and doing the
>     Right Thing from the developer's perspective.

Right, but it's also the case that adding more ini entries sorely for
certain backwards compatibilities could make it harder for us to write
portable scripts and could definitely generate a disgusting number of
bogus PR's as in the case of register_globals. Therefore any attempts of
such mitigation will not likely end up with a certain success after all.

As a bunch of incompatibilities are to be addressed in php5, I suppose we
don't always have to bother bringing light to such compromise. We need to
progress somehow.

Moriyoshi

Sascha Schumann

23 years ago

> Right, but it's also the case that adding more ini entries sorely for
> certain backwards compatibilities could make it harder for us to write
> portable scripts and could definitely generate a disgusting number of
> bogus PR's as in the case of register_globals. Therefore any attempts of
> such mitigation will not likely end up with a certain success after all.

It's my understanding in this case that you can write
portable scripts even with the ini switch in place.  Thus,
there is no point in saying that scripting becomes harder due
to such a change.

> As a bunch of incompatibilities are to be addressed in php5, I suppose we
> don't always have to bother bringing light to such compromise. We need to
> progress somehow.

But we are making progress.  We correct PHP's behaviour while
enabling administrators to maintain legacy applications.
It's simply not always an option to fix the app, so let's
empower those who want to upgrade PHP without breaking
existing apps.

- Sascha