Re: Bug #12575 Updated: Session register & destroy flaws/bugs(?)

I think that your comments are a fair point, but given that session_start() will create or open/restore a previous session, affecting state of the script that's directly related to session state, surely session_destroy() should do the converse, destroying the backend and also the program state that session_start() introduced in the first place. Incidentally, when session_end() is implemented, it should possibly also clear registered variables, although that depends on whether you regard a closed session to still exist - which of course it technically does. Just because it's not actually open may not mean that values obtained from that session aren't an accurate reflection of the session, but the problem comes if you then change variables associated with a closed session because you then do have an incorrect view of session state. Perhaps variables that are associated with a closed session should then become 'const' or read only, and modifying them should create at least a warning, because this is likely to be symptomatic of a design flaw in the users application - they're changing session state that isn't going to take effect. Not all applications that call session_destroy() will be ending at that point, in fact for mine, it's merely beginning. If you link program state, which you are doing via session_register(), to a session, I think that this state should *always* accurately reflect the state of the session. Calling session_unset() may be useful to reset an active session, but if there's no session then there can be no data. In essence, once you've associated a variable to a session entity, you should always be able to look to that variable to determine an accurate reflection of the session state. - but perhaps we can agree to differ :-) Nick On Sun, Aug 05, 2001 at 06:34:22PM -0000, Bug Database wrote: > ID: 12575 > Updated by: rasmus > Reported By: nick@macaw.demon.co.uk > Old Status: Open > Status: Analyzed > Bug Type: Session related > Operating System: Linux > PHP Version: 4.0.6 > New Comment: > > I think this is consistent behaviour. session_start() brings data from your session backend > into your current script. session_destroy() destroys the session data in your session backend. It > does not and should not affect variables which are currently active in your script. The > session_start() and session_unset() functions are designed to affect the current active symbol > table.