php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #13831 Assigning to multi-dimensional $HTTP_SESSION_VARS array not restored
Submitted: 2001-10-25 19:42 UTC Modified: 2001-11-27 10:03 UTC
From: shelby at DownloadFAST dot com Assigned:
Status: Closed Package: Session related
PHP Version: 4.0.6 OS: FreeBSD 4.2
Private report: No CVE-ID: None
View Developer Edit
 [2001-10-25 19:42 UTC] shelby at DownloadFAST dot 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."

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-10-25 20:42 UTC] shelby at DownloadFAST dot com 
Further searching reveals this may be a duplicate or related to Bug id #12859.

Perhaps my example/explanation is more concise.
 [2001-11-24 20:09 UTC] 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-11-27 00:17 UTC] shelby at DownloadFAST dot 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-27 00:29 UTC] 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:48 UTC] shelby at DownloadFAST dot com 
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
 [2001-11-27 00:51 UTC] shelby at DownloadFAST dot com 
BTW, nothing is free.

Not even ignorance.
 [2001-11-27 00:57 UTC] cnewbill@php.net 
Yes, it is the way he and most of the people who volunteer their time goes about it.  The source is constantly changing and chances are pretty good if you've found a bug; one of the millions of other PHP users has found it as well and it's already been fixed or is known of.

So if you could take 10 minutes of your valuable time and perform a simple, concise test, then we would know if it is indeed still present in the code.

It may not be the most efficient system, but it works better if everyone does what they can.  If you're persistent on being anal about this, send me (cnewbill@elementalrain.com) your script(s) and I will test it myself.

-Chris
 [2001-11-27 05:41 UTC] jmoore@php.net 
Firstly we are here as voulenteers, we ask for your help as if you have reported a bug and we ask you to test with latest cvs it takes you ten maybe twenty mins to test it on your machine where you already have code available and set up, for us to set up things in an envornment similar to EVERY bug report we see it would take us a long time and thus less bugs would get fixed.

Form the looks of your script it looks like an error in your scripting to me but without seeing a smaple of your code I cant confirm this, please post the shortest test script possible that reproduces this behaviour.

We dont have hours to hunt for your bug and how to reproduce it or write scripts to reproduce it, if you dont want to test latest CVS then at least provide us with the shortest code snippet possible that reproduces the bug. Make sure that script has as few dependencies as posssible (IE no database connections, no special extensions and no includes.)

To be honest if you dont want to do either of the above its VERY unlikley any of use will be bothered to try and fix this for you either.

And dont complain its the way we work, mozzila works and many other opensource projects work.

- James
 [2001-11-27 08:53 UTC] sniper@php.net 
I asked to test the latest CVS as I _assume_ this was a bug that
was just recently FIXED there. I had tested it with my scripts and
so had couple of other people.

Reopen with a short example script if you can not reproduce this
with the snapshot.

--Jani
 [2001-11-27 10:03 UTC] shelby at DownloadFAST dot com 
You know what they about ASSUME.

For example, several people here ASSUME that it takes me 20 minutes to test the new CVS, but they don't realize that I pay someone to maintain a server with 4.0.6.  If I have to pay them to build a separate server to load latest CVS, then that is going to cost me $1000.

ASSUMPTIONS are the worst plague of programming.  We should always be deterministic.

Now if what you meant is "I am closing this and you can reopen if you discover the bug still exists in a later production release", then write that.  I think it would make more sense to "normal" people if you write what you mean, instead of passing orders around that merely look like you want to pass the buck.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue May 06 14:01:28 2025 UTC