> On Mon, 21 May 2001, [EMAIL PROTECTED] wrote:
> > Yes, I figured that was the issue. If $HTTP_SESSION_VARS is set then I
> > think it should take precedence. I think the current approach where
> > scripts written with register_globals set to Off do not work on servers
> > that have register_globals On is bad. Makes it pretty much impossible to
> > write portable session code.
>
> How about this scenario -- register_globals is on, session is loaded,
> $HTTP_SESSION_VARS['foo'] and $foo contain the same value, then user
> changes $foo, thinking it will be saved. But if you say
> $HTTP_SESSION_VARS value takes precedence, then his changes are lost --
> not too intuitive.
At least with this scenario the script that was written with
register_globals off will still work just fine. But I do see the problem.
$HTTP_SESSION_VARS is populated in regardless of the register_globals
setting, so people not used to using $HTTP_SESSION_VARS are going to have
a lot of problems changing existing session variables.
I guess logically we should make the global variable take precedence and
perhaps even export any changes to $HTTP_SESSION_VARS into the global
symbol table. Somewhat magical, but what else can we do here? I really
don't think we can live with the current situation.
-Rasmus
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
