Bug #13831 Updated: Assigning to multi-dimensional $HTTP_SESSION_VARS array not restored

ID: 13831 User updated by: shelby@DownloadFAST.com Reported By: shelby@DownloadFAST.com Status: Open Bug Type: Session related Operating System: FreeBSD 4.2 PHP Version: 4.0.6 New Comment: Who is freeloading? I reported the bug already and gave a concise example. Now sniper wants to mark it closed so he asked me to do more work, knowing if I don't respond he will mark it closed. I've seen his pattern in other bugs. Seems like sniper is the active person here, so I assume he must be the QA guy in charge here. If he wants to find out if it was fixed in latest CVS, he should test it, not order me to do more work. I made a contribution by taking the time to make the concise bug report. I don't need the bug fixed. I posted the bug to help out by giving a more concise example of a bug posted by another person. I was trying to help sniper test it more quickly. He shows his appreciation by ordering me to test it. Sigh 2x Previous Comments: ------------------------------------------------------------------------ [2001-11-27 00:29:10] cnewbill@php.net Maybe you should appreciate the fact that this is a "free" service and if your time is so valuable that you can't put in a percentage of what you get out then you are more than welcome to pay for commercial support http://www.zend.com/store/products/zendsupport.php. Freeloaders, Sigh ------------------------------------------------------------------------ [2001-11-27 00:17:30] shelby@DownloadFAST.com I am not paid to be your QA person. You test in the latest CVS. I don't even have the latest CVS installed, nor would I take the time to install it at my cost. The concise code example is already given in my original post. It says that the variable is not restored. Put it in a session and see if it is restored. Simply and that is your job sniper, not mine. Please appreciate the people who come here to spend their valuable time to help you by reporting by a bug. Or disrespect us by marking a bug as closed because we won't do your job for you. Sigh. ------------------------------------------------------------------------ [2001-11-24 20:09:09] sniper@php.net Please try the latest CVS snapshot from http://snaps.php.net/ and if you can reproduce this with it, add a complete but short example script into this report. ------------------------------------------------------------------------ [2001-10-25 20:42:44] shelby@DownloadFAST.com Further searching reveals this may be a duplicate or related to Bug id #12859. Perhaps my example/explanation is more concise. ------------------------------------------------------------------------ [2001-10-25 19:42:08] shelby@DownloadFAST.com I did: session_register( "SESSION" ); The following array element is not restored on session_start() of next page: $HTTP_SESSION_VARS["SESSION"]["class_name"] = new ClassName(); Whereas any of the following are restored (each tested independently): $SESSION["class_name"] = new ClassName(); $GLOBALS["SESSION"]["class_name"] = new ClassName(); $HTTP_SESSION_VARS["SESSION"] = new ClassName(); I also have a question which I have not tested. Obviously this question affects whether I can work around this bug with register_globals off. When register_globals is turned off, will $GLOBALS["SESSION"] still represent the same registed session variable? Or am I forced to use $HTTP_SESSION_VARS in that case? The Sessions documentation does not mention $GLOBALS and seems to imply strongly the latter where it says: Quoted from http://www.php.net/manual/en/ref.session.php: "If track_vars is enabled and register_globals is disabled, only members of the global associative array $HTTP_SESSION_VARS can be registered as session variables. The restored session variables will only be available in the array $HTTP_SESSION_VARS." ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=13831&edit=1