Weel... as NotNowJohn has said, if register_globals=off, the Frank's solution won't work. If register_globals=on, it works, but you're actually using a copy of the variable, not the variable itself. So, if you're trying to use an environment variable, for example, using $_ENV['nameofvariable'] assures that. If you use the copy, I mean, only $nameofvariable, its value can be changed by the url. It seems a bit dangerous, doesn't it? The performance (because php needs to copy the values of environment, get, post, session and cookies variables) is decreased...
In other words, keep register_globals=off and get used to it.

:o)
Fernando.

Hi all,

thanks for reply, I'm discovering right now the greate flexibility of $HTTP_GET_VARS and $HTTP_POST_VARS.

Cheers,
Frank

Do _NOT_ use $HTTP_xxx_VARS. Use $_xxx instead.

HTTP_xxx_VARS was deprecated a long time ago now. They still work but they act quite differently than their $_xxx superglobal counterparts.

$_xxx vars are "superglobals", whereas $HTTP_xxx_VARS are regular variables. That means that $_xxx is always in scope, even within a function. You don't have to import it into function or class scope.

Also -- the variables stored in HTTP_xxx_VARS are COPIES of the values in the superglobals. Changing one does not change the other. Same thing with $_REQUEST.

$_REQUEST is also a Bad Thing (imho) because you, the programmer, should know where your data is coming from. When you use $_REQUEST, you're saying "I'll take this value from wherever it comes in, be it GET, POST, or SESSION."

That sounds a lot like a lazy assumption, and laziness is the root of almost all bugs and security holes.

With $_REQUEST, there is always the chance that there will be variable naming conflicts. Suppose you have a session variable named "username", and someone submits a form with an input field named "username". If, on the recieving page of that script, you access the value via $_REQUEST['username'], which username are you getting?

Are you sure it's the right one? Why not always be explicit?

For more info, read my old FAQ at:

http://p2p.wrox.com/archive/beginnin...2002-11/17.asp


Take care,

Nik
http://www.bigaction.org/