Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:1642
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <3EC6A91D.1010306@caraveo.com>
Date: Sat, 17 May 2003 14:26:53 -0700
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
MIME-Version: 1.0
To:  ilia@prohost.org
CC: Moriyoshi Koizumi <moriyoshi@at.wakwak.com>, 
 php-internal <internals@lists.php.net>
References: <20030518054728tC&SyF@at.wakwak.com> <200305171701.49446.ilia@prohost.org>
In-Reply-To: <200305171701.49446.ilia@prohost.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Apache2 SAPI behaviour regarding PATH_TRANSLATED
From: shane@caraveo.com (Shane Caraveo)

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