From: Reini U. <ru...@x-...> - 2002-09-02 15:02:24
|
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'); > } FYI: php > 4.1.0 will support $HTTP_SERVER_VARS and friends. The superglobals $_SERVER and friends are just handy references to those, because they are always global. Because this code is global, it is okay. In a function you would have to declare it global. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Reini U. <ru...@x-...> - 2002-09-04 07:16:59
|
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/ |
From: Jeff D. <da...@da...> - 2002-09-04 15:58:25
|
> 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... |
From: Lawrence A. <la...@us...> - 2002-09-02 18:31:48
|
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 ] |
From: Reini U. <ru...@x-...> - 2002-09-03 09:16:47
|
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/ |
From: Joby W. <joby@u.washington.edu> - 2002-09-03 21:27:24
|
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? |
From: Jeff D. <da...@da...> - 2002-09-03 22:08:28
|
> 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. |
From: Lawrence A. <la...@us...> - 2002-09-04 06:56:18
|
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! |