变量
在线手册：中文 英文
PHP手册

预定义变量

PHP 提供了大量的预定义变量。由于许多变量依赖于运行的服务器的版本和设置，及其它因素，所以并没有详细的说明文档。一些预定义变量在 PHP 以命令行形式运行时并不生效。有关这些变量的详细列表，请参阅预定义变量一章。

Warning

PHP 4.2.0 以及后续版本中，PHP 指令 register_globals 的默认值为 off。这是 PHP 的一个主要变化。让 register_globals 的值为 off 将影响到预定义变量集在全局范围内的有效性。例如，为了得到 DOCUMENT_ROOT 的值，将必须使用 $_SERVER['DOCUMENT_ROOT'] 代替 $DOCUMENT_ROOT，又如，使用 $_GET['id'] 来代替 $id 从 URL http://www.example.com/test.php?id=3 中获取 id 值，亦或使用 $_ENV['HOME'] 来代替 $HOME 获取环境变量 HOME 的值。

更多相关信息，请阅读 register_globals 的配置项条目，安全一章中的使用 Register Globals，以及 PHP » 4.1.0 和 » 4.2.0 的发布公告。

如果有可用的 PHP 预定义变量那最好用，如超全局数组。

从 PHP 4.1.0 开始，PHP 提供了一套附加的预定数组，这些数组变量包含了来自 web 服务器（如果可用），运行环境，和用户输入的数据。这些数组非常特别，它们在全局范围内自动生效，例如，在任何范围内自动生效。因此通常被称为自动全局变量（autoglobals）或者超全局变量（superglobals）。（PHP 中没有用户自定义超全局变量的机制。）超全局变量罗列于下文中；但是为了得到它们的内容和关于 PHP 预定义变量的进一步的讨论以及它们的本质，请参阅预定义变量。而且，你也将注意到旧的预定义数组（$HTTP_*_VARS）仍旧存在。自 PHP 5.0.0 起, 用 register_long_arrays 设置选项可禁用 长类型的 PHP 预定义变量数组。

Note: 可变变量

超级全局变量不能被用作可变变量。

Note:

尽管超全局变量和 HTTP_*_VARS 同时存在。但是他们并不是同一个变量，所以改变一个的值并不会对另一个产生影响。

如果某些 variables_order 中的变量没有设定，它们的对应的 PHP 预定义数组也是空的。

变量
在线手册：中文 英文
PHP手册
PHP手册 - N: 预定义变量

用户评论:

mvpetrovich (18-May-2008 06:52)

Here is a function to get all your variables of interest.

It uses the "parse_str function" and lets you enter your variable names as a space-delimited list.  It's a quick way to get your variables.  Note that in this function I strip tags, and trim the result.  The function produces a "Query String" which is fed into the "parse_str_function."

Example:
<?php
  parse_str(PostGetStr('NAME PASSWORD SUBMIT','POST'));
?>

This will produce three variables, $NAME, $PASSWORD, and $SUBMIT.  If they were undefined, they will be null strings, ie, $NAME=''.

<?php
function PostGetStr($str,$type){
  $VARS = explode(' ',$str);
  $RESULT = '';
  if($type == 'POST'){
     foreach($VARS as $PV) if(isset($_POST[$PV])) {
       $RESULT .= "$PV=".trim(strip_tags($_POST[$PV])).'&';
       } else {$RESULT .= "$PV=&";}
  } elseif($type == 'GET'){
     foreach($VARS as $PV) if(isset($_GET[$PV])) {
       $RESULT .= "$PV=".trim(strip_tags($_GET[$PV])).'&';
       } else {$RESULT .= "$PV=&";}
  } elseif($type == 'BOTH'){
     foreach($VARS as $PV) if(isset($_REQUEST[$PV])) {
       $RESULT .= "$PV=".trim(strip_tags($_REQUEST[$PV])).'&';
     } else {$RESULT .= "$PV=&";}
  }
  $RESULT = substr($RESULT,0,-1);
  return $RESULT;
}

?>

root at mantoru dot de (31-Jan-2008 08:56)

To tokie at hanmail dot net: You took that out of context -- it is merely a recommendation.

If your variables_order setting does not contain "E", $_ENV is still useful. Every call to getenv will be "cached" in $_ENV, so you can do this:

<?php
// variables_order = GPCS
var_dump(isset($_ENV['PATH'])); // bool(false)
getenv('PATH');
var_dump(isset($_ENV['PATH'])); // bool(true)
?>

For some reason, it does not work with with own environment variables. The above example with PHP_TEST instead of PATH would fail (if it is set via putenv).

fabrizio at bibivu dot com (28-Jun-2007 03:05)

theonly_DD32, I refined your function a little bit

<?php
    function long_to_GET($PATH_INFO=''){
        /**
        * This function converts info.php/a/1/b/2/c?d=4 TO
        * array ( [d] => 4 [a] => 1 [b] => 2 [c] => array ( [d] => 4 ) )
        * got this function from http://php.net/GLOBALS
        **/
        if($PATH_INFO=='' && isset($_SERVER['PATH_INFO']) && $_SERVER['PATH_INFO'] != ''){
            $PATH_INFO = $_SERVER['PATH_INFO'];
        }
        if($PATH_INFO != ''){
            //Split it out.
            $tmp = explode('/',$PATH_INFO);
            //Remove first empty item
            unset($tmp[0]);
            //Loop through and apend it into the $_GET superglobal.
            for($i=1;$i<=count($tmp);$i+=2){
                if(strpos($tmp[$i],'?')!==false){
                    $tmp1 = explode('?',$tmp[$i]);
                    parse_str(isset($tmp1[1])?$tmp1[1]:'',$_GET[$tmp1[0]]);
                    $i--;
                } else {
                    $_GET[$tmp[$i]] = isset($tmp[$i+1])?$tmp[$i+1]:'';
                }
            }
        }
    }

?>

tokie at hanmail dot net (23-May-2007 02:45)

I found something you should know in the settings file (php.ini) :

;     The environment variables are not hashed into the $_ENV.  To access
;     environment variables, you can use getenv() instead.

so... don't be surprised if you print_r($_ENV) and you get NOTHING!!

pinkgothic at gmail dot com (20-Apr-2007 03:15)

Dealing with "superglobals" and functions is not as straightforward as it may seem when you're doing plenty manipulations.

For example:

<?php
  function some_other_method() {
    echo $_REQUEST['id'];
  }
  function some_method() {
    $_REQUEST['id'] = 440;
    some_other_method();
  }
?>

Calling some_method() will cause a warning-level error by PHP informing you that "id" is not set in some_other_method(). However, if you instead use:

<?php
  $_REQUEST['id'] = 0;
  function some_other_method() {
    echo $_REQUEST['id'];
  }
  function some_method() {
    $_REQUEST['id'] = 440;
    some_other_method();
  }
?>

Then the script will echo 440.

In consequence, if you manually attempt to add keys to the superglobals, those keys *aren't* automatically superglobal. The above example isn't very sensible, of course, but this can be a huge gotcha if you're juggling user data between functions and you're unwittingly being forced to work inside a function (e.g. via PHP include in TYPO3).

Unfortunately, global $_REQUEST['id'] won't save you, either - it causes a parse error - nor will a global $_REQUEST change anything after you've set the keys... consequently making it hard to conviniently 'hack' outdated scripts by making them believe they're still running in a different environment.

The only "solution" to this issue is to use parameters.

holger at doessing dot net (02-Feb-2007 02:07)

On the subject of permalinks and queries:
Say, you use an inexpensive subdomain of (e.g.) www.nice.net, thus www.very.nice.net, and that the domain owner has simply placed a frame at this particular location, linking to the actual address (ugly and subject-to-change) of your site.
Consequently, the actual site URI and various associated hashes and query strings are not immediately visible to the user. Sometimes this is useful, but it also makes bookmarking/permalinking impossible (the browser will only bookmark the static address in the top frame).
However, as far as the query strings go, there is workaround. Instead of providing users with permalinks to the actual URI (e.g. prtcl://weird.and.ugly/~very/ugly.php?stuff=here; may even be subject to change), I provide them with this: prtcl://www.very.nice.net?stuff=here.

In brief, I then use the following code to re-populate the $_GET array:

if (isset($_SERVER['HTTP_REFERER'])) { // If set, this page is running in a frame
    $uri = parse_url($_SERVER['HTTP_REFERER']); // grab URI of parent frame
    $querystring = ($uri['query']) ? $uri['query'] : false; // grab the querystring
    if ($querystring) {
        $vars = explode('&', $querystring); // cut into individual statements
        foreach ($vars as $varstring) { // populate $_GET
            $var = explode('=', $varstring);
            if (count($var) == 2) $_GET[$var[0]] = $var[1];
        }
    } // no, nothing to report from the parent frame
} // no, not using a parent frame today...

If the actual host address is ever changed, users entering the frame (with the nicer address) will be using the new (and ugly) URI, but this way the old query strings will be available to the new address also. The users will never again be bothered by you moving to another neighborhood.

Joe Marty (24-Jan-2007 07:48)

I think it is very important to note that PHP will automatically replace dots ('.') AND spaces (' ') with underscores ('_') in any incoming POST or GET (or REQUEST) variables.

This page notes the dot replacement, but not the space replacement:
http://us2.php.net/manual/en/language.variables.external.php

The reason is that '.' and ' ' are not valid characters to use in a variable name.  This is confusing to many people, because most people use the format $_POST['name'] to access these values.  In this case, the name is not used as a variable name but as an array index, in which those characters are valid.

However, if the register_globals directive is set, these names must be used as variable names.  As of now, PHP converts the names for these variables before inserting them into the external variable arrays, unfortunately - rather than leaving them as they are for the arrays and changing the names only for the variables set by register_globals.

yarco dot w at gmail dot com (10-Aug-2006 03:13)

And you should know

$_POST is not a reference of $HTTP_POST_VARS

So, if you change $_POST, there are no change to $HTTP_POST_VARS.

I?igo Medina (05-May-2006 09:22)

It is true. I usually write variables in this way: $chuckNorrisFilms. So one almost never finds problems.

johnphayes at gmail dot com (12-Apr-2006 06:36)

I haven't found it anywhere else in the manual, so I'll make a note of it here - PHP will automatically replace any dots ('.') in an incoming variable name with underscores ('_'). So if you have dots in your incoming variables, e.g.:

example.com/page.php?chuck.norris=nevercries

you can not reference them by the name used in the URI:
//INCORRECT
echo $_GET['chuck.norris'];

instead you must use:
//CORRECT
echo $_GET['chuck_norris'];

jk at ricochetsolutions dot com (28-Mar-2006 09:41)

here is a one line snippet to do the same as DD32's func

@preg_replace(
   "/(?i)([a-z0-9_]+)\/([a-z0-9_]+)\/?/e",
   '$_GET[\'$1\'] = "$2";',
   ((isset($_SERVER['PATH_INFO'])) ? $_SERVER['PATH_INFO'] : '')
);

may be faster, it may not ;o

DD32=theonly_DD32[&amp;]yahoo.com.au (19-Mar-2006 01:43)

I have this function in my main files, it allows for easier SEO for some pages without having to rely on .htaccess and mod_rewrite for some things.
<?php
    function long_to_GET(){
        /**
        * This function converts info.php/a/1/b/2/c?d=4 TO
        * Array ( [d] => 4 [a] => 1 [b] => 2 [c] => )
        **/
        if(isset($_SERVER['PATH_INFO']) && $_SERVER['PATH_INFO'] != ''){
            //Split it out.
            $tmp = explode('/',$_SERVER['PATH_INFO']);
            //Remove first empty item
            unset($tmp[0]);
            //Loop through and apend it into the $_GET superglobal.
            for($i=1;$i<=count($tmp);$i+=2){ $_GET[$tmp[$i]] = $tmp[$i+1];}
        }
    }
?>

Its probably not the most efficient, but it does the job rather nicely.

DD32

(08-Mar-2006 01:51)

there is a difference to the scope of eg. java: variables that are defined inside a block are also defined outside of  the brackets.

eg. this works:

if {true}
{
  $a = 'it works';
}

echo $a;

Graeme Jefferis (13-Sep-2005 12:06)

I find this sort of thing consistently useful for dealing with superglobals in safety and comfort.
<?php
foreach ($_POST as $key => $value)
{
        switch ($key)
        {
                case "submitted_var_1":
                case "submitted_var_2":
                case "submitted_var_3":
                        $$key = $value; break;

                case "dangerous_var":
                        $value = do_something_special_with($value);
                        $$key = $value;
                        break;
        }
}
?>

Nicole King (12-Sep-2005 07:01)

There seems to a maximum size of key that you can use for the $_SESSION array on php5. If you exceed this length, which seems to be around 72 characters, the value is stored in the array, but is not serialised and restored later in the session (ie. when a subsquent page is processed). The same restriction *might* apply to other system-defined arrays.

webdesign at benking dot com (29-Aug-2005 10:33)

# this is a follow-up to kasey at cornerspeed's 14-Jun-2004 08:33 post and debabratak at softhome's 14-Mar-2003 12:59 post, minus sessions but including a safety mechanism to block unwanted variables...

# if you are like me and do not want to have to type $_POST[some_var] to get to all your passed variable data, you can safely convert all the data to the variable names (so it is like old style php) by using a pre-defined allowed arg names list like this;

$allowed_args = ',f_name,l_name,subject,msg,';

foreach(array_keys($_POST) as $k) {
    $temp = ",$k,";
    if(strpos($allowed_args,$temp) !== false) { $$k = $_POST[$k]; }
}

# then you can use the programmer friendly (less typing) vars like so;
echo "Hello $f_name";

# make sure you have commas in front of and after each var name in the $allowed_args list, so strpos will never surprise you by mistakingly finding an unwanted var name within another var name

dompody [at] gmail [dot] com (15-May-2005 01:08)

To urbanheroes:

version_compare() is only in PHP version 4.1.0 and up. This completely negates your function, since if the version is less than 4.1.0 it will generate an error anyway. The better solution is to do what is stated in the post above yours:

<?php
if (!isset($_SERVER))
{
   $_GET    = &$HTTP_GET_VARS;
   $_POST    = &$HTTP_POST_VARS;
   $_ENV    = &$HTTP_ENV_VARS;
   $_SERVER  = &$HTTP_SERVER_VARS;
   $_COOKIE  = &$HTTP_COOKIE_VARS;
   $_REQUEST = array_merge($_GET, $_POST, $_COOKIE);
}
?>

Include that before everything else in your script and it will fix the flaw.

myfirstname dot barros at gmail dot com (27-Apr-2005 03:10)

vars in $_REQUEST are *not* a reference to the respective $_POST and $_GET and $_COOKIE ones.

Consider:
http://site.com/index.php?avar=abc

index.php:
<?php
$_GET['avar'] = 'b';
print_r($_GET); print('<br>');
print_r($_REQUEST);
?>

output:
Array ( [avar] => 'b' )
Array ( [avar] => 'abc' )

sendoshin[at]noodleroni[dot]com (27-Apr-2005 01:58)

There is one way to safely execute PHP code files without running the risk of compromising your own code.  A prior note pointed out that the code being evaluated would still have access to globals using the global keyword.  While this is a valid point, there's one other approach to be looked at - one which actually gives you much more ability than just unsetting some variable references.  It's known as code parsing.

The specifics would be different and much more complex in a deployed site, but here's an extremely strip-down example of how to restrict access to global variables:

<?php
    while ($x = stristr ($code_to_eval, "global")) {
        $temp = substr ($code_to_eval, 1, $x-1);
        $temp .= substr ($code_to_eval, stristr ($code_to_eval, ";", $x) + 1);
        $code_to_eval = $temp;
    }
    $ret_val = eval ($code_to_eval);
?>

Of course, that's just a rudimentary example, and a deployment version would have much more checking involved, but parsing the file before you eval it lets you remove any code you don't want to let run, thus making it as safe as your parsing rules.

lanny at freemail dot hu (10-Apr-2005 10:32)

From PHP 5.0.3 long predefined arrays such HTTP_GET_VARS got disabled by default. For backward compatibility you can enable them in php.ini:

register_long_arrays = On

I sugget a big WARNING up there like that one with the resister_globals.

Anyway.. I cannot understand why they do such tings all the time.

(16-Feb-2005 12:35)

php.net uses this

// Backward compatible array creation. After this point, the
// PHP 4.1.0+ arrays can be used to access variables coming
// from outside PHP. But it should be noted that these variables
// are not necessarily superglobals, so they need to be global-ed!
if (!isset($_SERVER))
{
    $_GET     = &$HTTP_GET_VARS;
    $_POST    = &$HTTP_POST_VARS;
    $_ENV     = &$HTTP_ENV_VARS;
    $_SERVER  = &$HTTP_SERVER_VARS;
    $_COOKIE  = &$HTTP_COOKIE_VARS;
    $_REQUEST = array_merge($_GET, $_POST, $_COOKIE);
}

$PHP_SELF = $_SERVER['PHP_SELF'];

kasey at cornerspeed dowt com (15-Jun-2004 01:33)

I have a few points to note to (debabratak at softhome dot net).  Firstly, extracting all your variables from the global variable arrays is rather cumbersome and possibly unsafe.  This causes longer run times, and wastes more memory.  Then, your script is starting the session before it parses the superglobals.  Bad things can happen because of this:

<?php

// user sent a GET header with key = secret_access, val = true, so

echo $_GET["secret_access"]; // output: true
echo $secret_access; // output:

session_start();

// in previous logic, you set session variable $secret_access = false

echo $_SESSION["secret_access"]; // output: false
echo $secret_access; // output: false

extract_globals();  // Globals put into "normal" variables

echo $_GET["secret_access"]; // output: true
echo $_SESSION["secret_access"]; // output: false
echo $secret_access; // output: true

// VARIABLES ARE COMPROMISED!
// DO NOT USE $secret_access !
// USE $_SESSION["secret_access"] instead !!!

?>

Secondly, I would like to point out the fact that all $_POST, $_GET, and $_COOKIE variables are intrinsically unsafe anyway.  Users can create their own scripts in the language of their choosing (PHP, ASP, JSP, etc.) that generate those headers to send to your PHP program via socket connections.  PHP cannot determine that these headers are any less valid than the ones sent by a web browser, so it parses them and places them in the $_POST, $_GET, or $_COOKIE variables.

The best practice is to use $_SESSION variables to validate the user before making any decisions based on form data.  e.g.:

<?php
session_start();
if (isset($_SESSION["valid"]))
{
    // all your program decisions and database interactions can go here
    if (isset($_POST["button_name"]))
    {
        ...
    }
    ...
}
elseif (isset($_POST["submit_login"]))
{
    if (($_POST["username"] == "foo") AND ($_POST["password"] == "bar"))
    {
        $_SESSION["valid"] = true;
        ...
    }
    else
    {
        session_unset();
        session_destroy();
        $error_msg = "Invalid username or password";
        $result_page = "login.php";
    }
}
elseif (isset($logoff))
{
    session_unset();
    session_destroy();
    $success_msg = "You have logged off successfully";
    $result_page = "login.php";
}
else
{
    session_unset();
    session_destroy();
    $result_page = "login.php";
}
require ($result_page);
?>

Session variables are orders of magnitude harder to compromise than POST, GET, and COOKIE data, since the server keeps track of session id's, and the session id is unique to each client and somewhat randomly generated.  If security is an ultimate concern, then you need to use SSL in case your traffic can be sniffed (since the session cookie is passed plain text to the client).

In summary, extracting out all the superglobals to normal variable names is not a good idea for reasons of security and ambiguity, not to mention wasted CPU cycles.  For private applications (ones that you don't want just anyone to be able to access), the only ways you can prevent malicious access is to 1) use sessions to ensure that the user is valid (for that page), and 2) use SSL-encryption to prevent session-hijacking.

Kasey

in reply to:
--------------------------------------------------------------
 debabratak at softhome dot net
14-Mar-2003 12:59
After having register_globals = off, I am using the following piece of code to get all the variables created for me. I have put this code in a separate file and just make it require_once() on top of every page.

session_start();
$ArrayList = array("_GET", "_POST", "_SESSION", "_COOKIE", "_SERVER");
foreach($ArrayList as $gblArray)
{
   $keys = array_keys($$gblArray);
   foreach($keys as $key)
   {
       $$key = trim(${$gblArray}[$key]);
   }
}

This pulls out all the possible variables for me, including the predefined variables, so I can keep coding the old style. Note that, this code does not handle the $_FILE.

Hope this helps someone.

bryan at nolifeline dot com (10-May-2004 08:07)

to marcbender at mail dot com

unset the globals

use a preg_replace ( pattern: |\;[^\;]*$i[^\;]*\;|Uis, replacement: ";", where $i is the name of any function/variable you wish to prevent access to.) on the code-to-be-evaled.  ideas are "global", "fopen", "mysql_connect", etc.  You know, anything that you wouldn't want to give a hyperactive 13 year old access to.

execute the code.

bryan at nolifeline dot com (10-May-2004 07:59)

This code needs slightly changed...

function remap_globals() {

   global $GET_VARS, $POST_VARS, $COOKIE_VARS, $SESSION_VARS, $SERVER_VARS, $ENV_VARS;

   $parser_version = phpversion();

   if ($parser_version <= "4.1.0") {
     $GET = &$GET_VARS;
     $POST = &$POST_VARS;
     $COOKIES = &$COOKIE_VARS;
     $SESSION = &$HTTP_SESSION_VARS;
     $SERVER = &$HTTP_SERVER_VARS;
     $ENV = &$HTTP_ENV_VARS;
   }
   if ($parser_version >= "4.1.0") {
     $GET = &$_GET;
     $POST = &$_POST;
     $COOKIES  = &$_COOKIE;
     $SESSION  = &$_SESSION;
     $SERVER = &$_SERVER;
     $ENV = &$_ENV;
   }
}

Note the ampersands.  They ensure that the variables act _exactly_ like the superglobal components, ie: changing $SESSION will update $_SESSION and thus update the local session files.

So yeah.  I don't know what the PHP name for that is, but in C it's called dereferencing, and I've seen it done in function definitions in myriad people's code, but not once in a standard variable situation.  Oh well.  Can't be creative all the time ^_^

marcbender_AT_mail_DOT_com (18-Apr-2004 10:23)

-Security issue-

In response to lopez at yellowspace,

You provided a method for executing potentially unsafe code:

> function safeEval($evalcode) {
>    unset($GLOBALS);
>    unset($_ENV);
>    // unset any other superglobal...
>    return eval($evalcode);
> }

Your method, though clever, won't work.  The problem is the way that PHP handles function scope.  If $evalcode contains a function declaration, and runs that function, the "unset"s will be effectively useless inside the body of that function.

Try running the above code with $evalcode set as follows:

<?php
$evalcode='f();
function f() {
   $GLOBALS["_SERVER"] = "compromised";
}';
?>

Then print $_SERVER and see what you get.

Another problem is that the "global" directive will always grant access to global variables.  Try this one:

<?php
$evalcode='global $a;
$a = "compromised";';
?>

$a will of course be changed at the global level.  I don't know if it's supposed to work this way, but on my system (PHP 4.3.4) you can do the same to any superglobal by importing it using "global".

As far as I can tell, there is NO way to execute potentially unsafe code without a lot of risk.  With the sloppy way that PHP deals with function scope etc., there isn't much hope that it ever will be.  What we'd need is (at least):
  - a way to disable the "global" directive (restrictive eval).
  - a way to shut off any write-access to superglobals within untrusted functions.

The first wouldn't be too hard to implement.  The second, on the other hand, is practically impossible IMHO.

mark at pitchpipe dot org (26-Oct-2003 06:21)

I had always mistakenly assumed that superglobal $_COOKIE (while preferred) was identical to the outdated $HTTP_COOKIE_VARS.  However, if you assign:

$_COOKIE['destroyWorld'] = "true";
if (isset($HTTP_COOKIE_VARS['destroyWorld'])) {
   $temp =& new Armeggedon();
   $temp->pushRedButton();
 }

then the world will be safe forever.  Might throw off a newbie, or someone like me who was updating really old code bit-by-bit.

wagner at cesnet dot cz (29-Sep-2003 04:15)

The redirected pages by response codes 301, 302, 303 change the request method always to GET, that's why $HTTP_POST_VARS are lost. It is described in Apache documentation.

joker at vip dot hr (09-Sep-2003 03:42)

If anyone of you have a problem with uploading files with globals off here is the solution... just add this to the top of the code:

reset ($_FILES);
while (list ($key, $val) = each ($_FILES)) {
    ${$key}=$_FILES[$key]['tmp_name'];
    while (list ($key1, $val1) = each ($val)) {
        ${$key."_".$key1}=$_FILES[$key][$key1];
    }
}

   Daniel

alexsp at olywa dot net (03-May-2003 03:26)

For those of us who don't have the luxery of upgrading to the latest version of PHP on all of the servers we use but want to use the same variable names that are used in the latest version for super global arrays here's a snippet of code that will help:
    // Makes available those super global arrays that are made available
    // in versions of PHP after v4.1.0.
    if (isset ($HTTP_SERVER_VARS))
    {
        $_SERVER = &$HTTP_SERVER_VARS;
    }
   
    if (isset ($HTTP_GET_VARS))
    {
        $_GET = &$HTTP_GET_VARS;
    }
   
    if (isset ($HTTP_POST_VARS))
    {
        $_POST = &$HTTP_POST_VARS;
    }
   
    if (isset ($HTTP_COOKIE_VARS))
    {
        $_COOKIE = &$HTTP_COOKIE_VARS;
    }
   
    if (isset ($HTTP_POST_FILES))
    {
        $_FILES = &$HTTP_POST_FILES;
    }
   
    if (isset ($HTTP_ENV_VARS))
    {
        $_ENV = &$HTTP_ENV_VARS;
    }
   
    if (isset ($HTTP_SESSION_VARS))
    {
        $_SESSION = &$HTTP_SESSION_VARS;
    }
The only downfall to this is that there's no way to make them super global. Chances are, though, if you're using a lot of global arrays in your code you should consider a code redesign!  :)  Hope this helps.

(01-May-2003 05:06)

In reply to destes at ix dot netcom dot com dot nospam:

It's possible for a HTTP client to spoof HTTP_X_FORWARDED_FOR, and set it to a fake IP number.  It's more secure to use this code and log BOTH the ip and the proxy ip.

if ($_SERVER["HTTP_X_FORWARDED_FOR"]) {
   if ($_SERVER["HTTP_CLIENT_IP"]) {
    $proxy = $_SERVER["HTTP_CLIENT_IP"];
  } else {
    $proxy = $_SERVER["REMOTE_ADDR"];
  }
  $ip = $_SERVER["HTTP_X_FORWARDED_FOR"];
} else {
  if ($_SERVER["HTTP_CLIENT_IP"]) {
    $ip = $_SERVER["HTTP_CLIENT_IP"];
  } else {
    $ip = $_SERVER["REMOTE_ADDR"];
  }
}

echo "Your IP $ip<BR>\n";
if (isset($proxy)) {
  echo "Your proxy IP is $proxy<BR>\n";
}

LouisGreen at pljg dot freeserve dot co dot uk (25-Mar-2003 06:22)

It seems that when you wish to export a varible, you can do it as return $varible, return an array(), or globalise it. If you return something, information for that varible can only travel one way when the script is running, and that is out of the function.

function fn() {
   $varible = "something";

  return $variable;
}

echo fn();
OR
$newvariable = fn();

Although if global was used, it creates a pointer to a varible, whether it existed or not, and makes whatever is created in the function linked to that global pointer. So if the pointer was global $varible, and then you set a value to $varible, it would then be accessible in the global scope. But then what if you later on in the script redefine that global to equal something else. This means that whatever is put into the global array, the information that is set in the pointer, can be set at any point (overiden). Here is an example that might make this a little clearer:

function fn1() {

   global $varible; // Pointer to the global array
   $varible = "something";
}

fn1();
echo $varible; // Prints something
$varible = "12345";
echo $varible; // Prints 12345

function fn2() {

   global $varible; // Pointer to the global array
   echo $varible;
}

fn2(); // echos $varible which contains "12345"

Basically when accessing the global array, you can set it refer to something already defined or set it to something, (a pointer) such as varible you plan to create in the function, and later possibly over ride the pointer with something else.

Good Liam (19-Mar-2003 05:18)

Warning:
If you use dynamic variables in a local scope, the variable doesn't "know" when it should be a superglobal.  An example will help elucidate this:

function Example($Variable_Name='_POST') {
    print_r($$Variable_Name);
} // End Example

This would print out

NULL

To use a dynamic variable to reference a superglobal, you have to declare the value (not the name) as a global:

function WorkingExample($Variable_Name='_POST') {
    global $$Variable_Name;
    print_r($$Variable_Name);
} // End WorkingExample()

This would print out the contents of your $_POST variable.

This threw me when I first tried it, but it makes sense, in a way.

LouisGreen at pljg dot freeserve dot co dot uk (12-Mar-2003 10:36)

If you require access to Predefined Variables in different PHP/ servers versions and don't wish to mess about with how you access them, this little snippet of code might help you:

function fn_http_vars_access() {

   global $GET_VARS, $POST_VARS, $COOKIE_VARS, $SESSION_VARS, $SERVER_VARS, $ENV_VARS;

   $parser_version = phpversion();

   if ($parser_version <= "4.1.0") {
      $GET_VARS      = $GET_VARS;
      $POST_VARS     = $POST_VARS;
      $COOKIE_VARS   = $COOKIE_VARS;
      $SESSION_VARS  = $HTTP_SESSION_VARS;
      $SERVER_VARS   = $HTTP_SERVER_VARS;
      $ENV_VARS      = $HTTP_ENV_VARS;
   }
   if ($parser_version >= "4.1.0") {
      $GET_VARS      = $_GET;
      $POST_VARS     = $_POST;
      $COOKIE_VARS   = $_COOKIE;
      $SESSION_VARS  = $_SESSION;
      $SERVER_VARS   = $_SERVER;
      $ENV_VARS      = $_ENV;
   }
}

fn_http_vars_access();

(12-Feb-2003 06:12)

i just noticed that the free web server i'm running my scripts on still only knows the deprecated variable names (i.e. it uses $HTTP_POST_VARS instead of $_POST). to make scripts work both on updated servers and servers that are a bit out of date, i now use:

$variablename=(isset($_POST["variablename"])) ? $_POST["variablename"] : $HTTP_POST_VARS["variablename"];

lopez dot on dot the dot lists at yellowspace dot net (18-Jan-2003 02:11)

- Security Issue and workaround -
If You use "eval()" to execute code stored in a database or elsewhere, you might find this tip useful.

Issue:
By default, all superglobals are known in every function.
Thus, if you eval database- or dynamically generated code (let's call it "potentially unsafe code"), it can use _all_ the values stored in _any_ superglobal.

Workaround:
Whenever you want to hide superglobals from use in evaluated code, wrap that eval() in an own function within which you unset() all the superglobals. The superglobals are not deleted by php in all scopes - just within that function. eg:

function safeEval($evalcode) {
    unset($GLOBALS);
    unset($_ENV);
    // unset any other superglobal...
    return eval($evalcode);
}

(This example assumes that the eval returns something with 'return')

In addition, by defining such a function outside classes, in the global scope, you'll make sure as well that the evaluated ('unsafe') code doesn't have access to the object variables ($this-> ...).

(08-Jul-2002 09:46)

Wouldn't it be great if there was a variable called $_SERVER["PATH_USERHOME"]. Here is how to set it yourself:

$path_fs = split ("/", ltrim ($_SERVER["PATH_TRANSLATED"], "/"));
$path_fs_rev = array_reverse ($path_fs);

$path_http = split ("/", ltrim ($_SERVER["PHP_SELF"], "/"));
$path_http_rev = array_reverse ($path_http);

$num_same = 0;
while ($path_fs_rev[$num_same] == $path_http_rev[$num_same]) {
    $num_same++;
}

$path_userhome = array ();
$numdirs_userhome = sizeof ($path_http) - $num_same;
echo $numdirs_userhome;

for ($i = 0; $i < $numdirs_userhome; $i++) {
    array_push ($path_userhome, $path_http[$i]);
}

$_SERVER["PATH_USERHOME"] = "/" . implode ("/", $path_userhome) . "/";

print_r ($_SERVER["PATH_USERHOME"]);

;) Happy programming,

Peder

juancri at TAGnet dot org (01-Jun-2002 04:52)

If you try this:

<FORM action="hola">
  ....
</FORM>

and hola is a directory, you have to write the final slash (/) because the page is redirected from hola to hola/ and you'll lost the POST variables.

admin at SexDev dot com (25-Apr-2002 09:17)

The problem with empty HTTP_X_FORWARDED_FOR is because of anonymous proxy servers:

Anonymous - HTTP Proxy server does not send HTTP_X_FORWARDED_FOR variable to host, this improves privacy since your IP address cannot be logged.

High anonymity - HTTP Servers of this type dont send HTTP_X_FORWARDED_FOR, HTTP_VIA and HTTP_PROXY_CONNECTION variables. Host doesnt even know you are using proxy server an of course it doesnt know your IP address.

rick@independence,netI (24-Jul-2001 02:13)

It should be noted that $HTTP_RAW_POST_DATA only exists if the encoding type of the data is -not- the default of application/x-www.form-urlencoded, and so, to accessing raw post data from an HTTP form requires setting enctype= in your HTML.

mike at dbeat dot com (23-Nov-2000 02:30)

If you're running PHP as a shell script, and you want to use the argv and argc arrays to get command-line arguments, make sure you have register_argc_argv  =  on.  If you're using the 'optimized' php.ini, this defaults to off.