After reviewing I
was wondering if simply including this line at the top of all scripts

    import_request_variables("gP", "");

would eliminate the potential problem I would have if
register_globals gets turned off unexpectedly?

Other than the security reasons, is there any disadvantage to adding
this line?

John Hughes

--- Philip Olson <[EMAIL PROTECTED]> wrote:
> > 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
> >
> 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

Do You Yahoo!?
Yahoo! Health - your guide to health and wellness

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to