PhpWiki

On Monday, September 2, 2002, 4:02:18 PM, Reini Urban wrote:

RU> Lawrence Akka schrieb:
>> Added Files:
>>       RPC2.php 
>> // Intercept GET requests from confused users.  Only POST is allowed here!
>> // There is some indication that $HTTP_SERVER_VARS is deprecated in php > 4.1.0
>> // in favour of $_Server, but as far as I know, it still works.
>> if ($HTTP_SERVER_VARS['REQUEST_METHOD'] != "POST")  
>> {
>>     die('This is the address of the XML-RPC interface.  You must use XML-RPC calls to access information here');
>> }

RU> FYI:
php >> 4.1.0 will support $HTTP_SERVER_VARS and friends.
RU> The superglobals $_SERVER and friends are just handy references to 
RU> those, because they are always global.

RU> Because this code is global, it is okay.
RU> In a function you would have to declare it global.

Thanks Reini. I do not have 4.1.0 here.

I had in mind the comment in the php manual which says:
$_SERVER

"Variables  set by the web server or otherwise directly related to the
execution  environment  of  the  current  script. Analogous to the old
$HTTP_SERVER_VARS array (which is still available, but deprecated)."

[see
http://uk2.php.net/manual/en/language.variables.predefined.php#language.variables.superglobals
]

Lawrence Akka schrieb:
> Thanks Reini. I do not have 4.1.0 here.
> 
> I had in mind the comment in the php manual which says:
> $_SERVER
> 
> "Variables  set by the web server or otherwise directly related to the
> execution  environment  of  the  current  script. Analogous to the old
> $HTTP_SERVER_VARS array (which is still available, but deprecated)."
> 
> [see
> http://uk2.php.net/manual/en/language.variables.predefined.php#language.variables.superglobals
> ]

up to 4.2.2 they are still there. guess for 4.3 also (BTW: 4.3-rc2 is 
out), but for the upcoming 5.0 they might go away.
no problem, they can easily be created from the superglobals.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Reini Urban wrote:
>> I had in mind the comment in the php manual which says:
>> $_SERVER
>>
>> "Variables  set by the web server or otherwise directly related to the
>> execution  environment  of  the  current  script. Analogous to the old
>> $HTTP_SERVER_VARS array (which is still available, but deprecated)."
>>
>> [see
>> http://uk2.php.net/manual/en/language.variables.predefined.php#language.variables.superglobals 
>>
>> ]
> 
> 
> up to 4.2.2 they are still there. guess for 4.3 also (BTW: 4.3-rc2 is 
> out), but for the upcoming 5.0 they might go away.
> no problem, they can easily be created from the superglobals.

Do we want to make a policy on this?  $HTTP_SERVER_VARS is deprecated, 
and thus in the future may be dropped.  On the other hand old (unsecure) 
PHP installations will not support $_SERVER.  We really should use one 
or the other not both.

Personally, I support using the $_SERVER, $_GET, etc family of 
superglobals despite some possible breakage of old PHP installations, 
because it is the preferred way, eventually we will probably have to 
migrate to it anyway, and it is more elegant.

How many installations are on PHP < 4.1.0?  If this breakage is an issue 
we can if PHP version is < 4.1.0 set $_SERVER = $HTTP_SERVER_VARS, 
$_COOKIE = $HTTP_COOKIE_VARS, etc.

Or is the consensus to wait to convert until it is necesary?

jbw

BTW - Lawrence, why are you limited to < 4.1.0?

> If this breakage is an issue 
> we can if PHP version is < 4.1.0 set $_SERVER = $HTTP_SERVER_VARS, 
> $_COOKIE = $HTTP_COOKIE_VARS, etc.

That's not quite the same.  $_SERVER is always global, whereas
$HTTP_SERVER_VARS is not.  (I.e. within a function you have
to declare $HTTP_SERVER_VARS global before using it.)

> Or is the consensus to wait to convert until it is necesary?

That (waiting) would get my vote.  It seems to me to be a weak reason
to break backward compatibility (and change existing working code).
I personally doubt that $HTTP_SERVER_VARS is going away any time soon,
and if it does, it can be brought back with $HTTP_SERVER_VARS = &$_SERVER.

On Tuesday, September 3, 2002, 10:27:13 PM, Joby Walker wrote:


JW> Do we want to make a policy on this?  $HTTP_SERVER_VARS is deprecated, 
JW> and thus in the future may be dropped.  On the other hand old (unsecure) 
JW> PHP installations will not support $_SERVER.  We really should use one 
JW> or the other not both.

At  the  moment,  we  have  tried  to  keep the minimum version of php
required as low as possible. I think we specify 4.0.1pl2 (or something
like that) as the minimum.

JW> Personally, I support using the $_SERVER, $_GET, etc family of 
JW> superglobals despite some possible breakage of old PHP installations, 
JW> because it is the preferred way, eventually we will probably have to 
JW> migrate to it anyway, and it is more elegant.

JW> How  many installations are on PHP < 4.1.0?

A respectable number, I think

JW> If this breakage is an
JW> issue   we   can  if  PHP  version  is  <  4.1.0  set  $_SERVER  =
JW> $HTTP_SERVER_VARS, $_COOKIE = $HTTP_COOKIE_VARS, etc.

JW> Or is the consensus to wait to convert until it is necesary?

I vote for "If it ain't broke, don't fix it"! Let's wait until we need
to change.


JW> jbw

JW> BTW - Lawrence, why are you limited to < 4.1.0?

errr .... haven't got round to upgrading my internal test server yet!

Joby Walker schrieb:
> Reini Urban wrote:
>>> I had in mind the comment in the php manual which says:
>>> $_SERVER
>>>
>>> "Variables  set by the web server or otherwise directly related to the
>>> execution  environment  of  the  current  script. Analogous to the old
>>> $HTTP_SERVER_VARS array (which is still available, but deprecated)."
>>>
>>> [see
>>> http://uk2.php.net/manual/en/language.variables.predefined.php#language.variables.superglobals 
>>> ]
>>
>> up to 4.2.2 they are still there. guess for 4.3 also (BTW: 4.3-rc2 is 
>> out), but for the upcoming 5.0 they might go away.
>> no problem, they can easily be created from the superglobals.
> 
> Do we want to make a policy on this?  $HTTP_SERVER_VARS is deprecated, 
> and thus in the future may be dropped.  On the other hand old (unsecure) 
> PHP installations will not support $_SERVER.  We really should use one 
> or the other not both.
> 
> Personally, I support using the $_SERVER, $_GET, etc family of 
> superglobals despite some possible breakage of old PHP installations, 
> because it is the preferred way, eventually we will probably have to 
> migrate to it anyway, and it is more elegant.

I prefer the other way round.
$GLOBALS['HTTP_SERVER_VARS'] will always work with simple workarounds in 
prepend.php.
$_SERVER is a mess to maintain, because nobody will declare it global.

> How many installations are on PHP < 4.1.0?  If this breakage is an issue 
> we can if PHP version is < 4.1.0 set $_SERVER = $HTTP_SERVER_VARS, 
> $_COOKIE = $HTTP_COOKIE_VARS, etc.
> 
> Or is the consensus to wait to convert until it is necesary?

Keep our style and add:

if (empty($HTTP_ENV_VARS)) {
   $HTTP_SERVER_VARS = &$_SERVER;
   $HTTP_GET_VARS    = &$_GET;
   $HTTP_POST_VARS   = &$_POST;
   $HTTP_COOKIE_VARS = &$_COOKIE;
   $HTTP_SESSION_VARS = &$_SESSION;
   $HTTP_ENV_VARS    = &$_ENV;
   // $_FILES not needed globally for now, only once in Request.
   // We should also find some way to support the CGI version by
   // using ENV instead of SERVER automatically.
}

when they become depricated.
I see a bigger problem with other apps which already converted to the 
new superglobals on "old" php 4.0.6 systems. They are still very common 
on ISP sites. I work for a large one.
-- 
Reini Urban  http://inode.at/

> Keep our style and add:
> 
> if (empty($HTTP_ENV_VARS)) {
>    $HTTP_SERVER_VARS = &$_SERVER;
...
>    // $_FILES not needed globally for now, only once in Request.
>    // We should also find some way to support the CGI version by
>    // using ENV instead of SERVER automatically.
> }

Yes ... and that reminds me (worth mentioning since we're on the
subject)...:

Actually very little code should need to access any of these
directly.  The code is Request should wrap just about all
of it (or could be fixed to do so.)  I think config.php
(because it executes before the Request is instantiated)
and Request.php are the only files which actually need to
access the $HTTP_*_VARS/$_* directly.  (And RPC2.php, too,
off course...)

PS: I admit Request could be better documented...