>  I have several scripts that take it for granted PHP will assign
>  variables to the information in the URL as in your example $a from
>  example.com/foo.php?a=apple

Okay, so they depend on the behavior that register_globals 
provides.

>  Will these scripts fail when my commercial Web host upgrades 
>  from PHP 4.1.x to 4.2?

It's not a matter of PHP versions, it's a matter of a 
simple PHP directive.  PHP 4.2.0 defaults to 
register_globals = off, this does not mean a host 
has to go by this default.  Ask them if it will be 
changing, odds are it will not without a warning.

>  If so, can I 'upgrade' my scripts now (again, PHP 4.1.x) to use 
>  $food = $_GET['a'] or $food = $_POST['a'] and prevent everything 
>  from crashing when PHP 4.2 is installed?

Yes you can.  I eluded to import_request_variables() and 
extract(), two functions that will allow you to do such 
things.  Please look them up in the manual (links below).
Also consider $_REQUEST, see the manual for details.

Also note that if you really want register_globals = on 
and the host has it off, you _may_ (depending on the hosts 
configurations) be able to use .htaccess (or equivalent) 
with something like:

  php_flag register_globals on
  
Yes there are a lot of options, variety is the spice of life.

Regards,
Philip Olson


>  --- Philip Olson <philip@[...].com> wrote:
>  > An issue/confusion of register_globals, global, and
>  > variable scope exists out there; here are some thoughts:
>  > 
>  >  a) As of PHP 4.2.0, register_globals defaults to off.
>  > 
>  >     This is a major change to consider.
>  >     register_globals is a PHP directive that lives in
>  >     php.ini, the configuration file that controls PHP.
>  > 
>  >     http://www.php.net/release_4_2_0.php
>  >     http://uk.php.net/manual/en/security.registerglobals.php
>  > 
>  >     Different server setups have different settings,
>  >     so not relying on register_globals = on will make
>  >     your scripts more portable.
>  > 
>  >  b) register_globals looks/sounds like global when
>  >     really they are very different topics.
>  > 
>  >    
>  > http://us.php.net/manual/en/configuration.php#ini.register-globals
>  >     http://www.php.net/manual/en/language.variables.scope.php
>  > 
>  >     register_globals will create $a from
>  > example.com/foo.php?a=apple
>  >     while when register_globals = off, $a will NOT exist.
>  >     One can always use $HTTP_GET_VARS or $_GET for this like so:
>  > 
>  >       print $_GET['a'];
>  > 
>  >     Use of import_request_variables() or extract() to act in a
>  >     similar fashion as register_globals is possible too.
>  > 
>  >     http://fr2.php.net/import_request_variables
>  >     http://ca.php.net/extract
>  > 
>  >  c) As of PHP 4.1.0, super/auto global arrays became available.
>  > 
>  >     The new predefined PHP variables such as $_POST, $_GET,
>  >     $_SERVER are identical to their existing counterparts of
>  >     $HTTP_POST_VARS, $HTTP_GET_VARS, etc. except that:
>  > 
>  >     1) The new autoglobal arrays are automagically global
>  >        while their sibling arrays ($HTTP_*_VARS) are not.
>  >          http://www.php.net/manual/en/reserved.variables.php
>  >     2) Shorter is better :)
>  >     3) They are different variables, $_GET is not a reference
>  >        to $HTTP_GET_VARS but rather they are two seperate
>  >        copies, same information.
>  >          http://fr2.php.net/release_4_1_0.php
>  > 
>  >     The manual discusses all the superglobals, others are 
>  >     $_REQUEST, $_FILES and $_SESSION.
>  > 
>  > Being that this is all relativly new, PHP is in sort
>  > of a mild transitional state.  The above announcements
>  > explain why.  People just starting out with PHP have
>  > slightly more homework to do than before.  But, these
>  > same people have less chance for security mistakes now.
>  > 
>  > And it's worth noting, register_globals does affect
>  > predefined SERVER variables too.  So when off the
>  > variables $DOCUMENT_ROOT, $PHP_SELF, etc. will NOT
>  > exist.  Go through $_SERVER or $HTTP_SERVER_VARS instead.
>  > This is something to consider when writing "portable"
>  > scripts (or hacking non-portable scripts to work).  A 
>  > possible usage is:
>  > 
>  >   // if register_globals is off, create server vars
>  >   if (!ini_get('register_globals')) {
>  >     extract($HTTP_SERVER_VARS);
>  >     print 'we just created $REMOTE_ADDR because register_globals is
>  > off';
>  >     print "\nREMOTE_ADDR: $REMOTE_ADDR";
>  >   } else {
>  >     print 'register_globals is on so $DOCUMENT_ROOT et al already
>  > exists';
>  >     print "\nDOCUMENT_ROOT: $DOCUMENT_ROOT";
>  >   }
>  > 
>  > Phew, hope that helps :)
>  > 
>  > Regards,
>  > Philip Olson
>  > 
>  > 
>  > -- 
>  > PHP General Mailing List (http://www.php.net/)
>  > To unsubscribe, visit: http://www.php.net/unsub.php
>  > 
>  
>  
>  __________________________________________________
>  Do You Yahoo!?
>  Yahoo! Health - your guide to health and wellness
>  http://health.yahoo.com
>  
>  -- 
>  PHP General Mailing List (http://www.php.net/)
>  To unsubscribe, visit: http://www.php.net/unsub.php
>  


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php