I should also mention that if you were to just open two seperate IE windows, and load myscriptA into one and myscriptB into the other, they DO function seperately, and so the sessions are not automatically spanned.

My ultimate goal is to have a way to have a session aware page launch a new window (that can also be session aware, with its own new session) that does NOT share the original window's session.

Everything I read seems that the intent is there to be able to on-demand create new sessions, and it stands to perfect reason that one might want to decide at some point in their PHP code that they wanted to break from any current session data (in cookies, memory, etc) and make a new session entry.

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

As the report page tells you, upgrade first. 

As I figured, you guys didn't read the whole thing. I specifically stated at the beginning that even though I was on an older version, others have had this problem in later versions, and the problem does not appear to have been identified or fixed in the change log or in the bug system.  I read every single post under the session bugs (took me like 6 hours) and saw nothing that specifically dealt with my problem. 

That's a canned response and a cop-out for you to just blame it on an old version of PHP unless you can tell me where its documented that it was fixed in a later version.  Since I already told you in my post that I have a logisitcal problem that prevents me from just simply upgrading right now, I think if you are so convinced it was fixed it would be nice and helpful if you would test the 2 very simple scripts on your updated version and see if you get the same thing as I do.

How can you call this a useful system if you all take the easy way to answer everyone's question?

This is not a tech support system.  This is a bug system.  It is up to you to prove to us that there is a bug and not up to us to prove to you that there isn't a bug.  Why is it hard for you to test your "simple" scripts on a recent version of PHP?  Are you saying that you don't have a single development machine on which you can install the latest PHP and test this stuff yourself?  If so, that is definitely not our problem.

I'm saying it seems wasted to install a whole new installation of PHP to test 10 lines of code, when someone with it already installed could test it in like 3 minutes for me and point me in the right direction.  

And noone said anything about you having to prove anything, I just expected maybe you'd have some common courtesy and either point out where it had been fixed, or test yourself to see if it had been fixed.  You took like 3 seconds to look at the 4.0.6 and just dismissed it.  That's sad and unprofessional.

Be that as it may, I'll play that game.  I'll waste my time to install the latest and greatest from PHP, and when I get the same problem, I expect to have some more decency shown toward a loyal and well-versed supporter of the language.

Look at the bug number for this bug report please.  Yes, this is the 23,764th report filed.  I don't know why you think installing a recent version of PHP and checking whether the problem still exists is a waste of your time.  You are helping us trying to solve *your* problem.  You damn well better be willing to put some effort into this and by whining that it is a waste of your time you are making sure that none of us are going to waste any of ours helping you.  We have 23,763 other reports we can go deal with.  

And yes, I have read through your entire report.  Why in the world are you not dumping the cookies that get sent from PHP and the ones that get sent from the browser and telling us what the cookie exchange looks like?  And what do the session files in your session directory look like for the two sessions?  Do a little bit of homework please and give us something to go on.

OK, so I found an idle deval server with the same OS and php 4.3.0 (relatively much more recent) on it. Tested the test scripts on it. Let me state that in my first posting, I misspoke slightly about the behavior.  When I said that window "A" lost its session entirely when window "B" was launched, that was incorrect.  What actually happens is that window "A" looses its ORIGINAL session association, and immediately takes on the new session id set in window "B".  The two windows are apparently inextricably connected since one launched the other. :(

In any case, I still found some weird/unexpected behavior with the way the session files are created and updated.  Here's a step by step trace of what I did:


window "A", loaded with myscriptA.php - screen output:

blah
e373b944e16776e47a365d455f4fcc02
Launch B 


session file on server:

/tmp/sess_e373b944e16776e47a365d455f4fcc02
test|s:4:"blah";

************************************************************

clicking "Launch B", 
opens window "B", loaded with myscriptB.php - screen output:

newwindowB
newTest

now, two session files exist:

/tmp/sess_e373b944e16776e47a365d455f4fcc02
test|s:4:"blah";

/tmp/sess_newwindowB


notice the sess_newwindowB file is blank right now. WHY DIDN'T session newwindowB get the "newTest" string assigned to test and stored into that session variable?
As seen later, the behavior should be that any change to the session should get immediately (at the end of script execution) written back to the session file on the server, right?


************************************************************

leaving window "B" open, switch back to window "A", click refresh - screen output:

blah
newwindowB
Launch B 

both session files still exist:

/tmp/sess_e373b944e16776e47a365d455f4fcc02
test|s:4:"blah";

/tmp/sess_newwindowB
test|s:4:"blah";


notice NOW that sess_newwindowB, instead of getting the "newTest" in it from window "B", has "blah" in it from the refresh of window "A".

************************************************************

refresh window "B", output in window B stays the same, then refresh window "A" again - screen output:

newTest_more
newwindowB
Launch B 

it's now obvious that sess_e373b944e16776e47a365d455f4fcc02 has been abandoned and is not being updated. its data remains the same.

/tmp/sess_newwindowB
test|s:12:"newTest_more";

notice that sess_newwindowB has not only "newTest" in it, which was surely from the refresh of window "B", but on the refresh of window "A", "_more" was added to the end of the variable and written right back to the session file. 

This is different than in the second step when window "B" changed the session the first time, which apparently didn't change the session file immediately as expected.

You never change the session name in your scripts,
so of course the last accessed script is the active one.
(the cookie name is propably PHPSESSID always.)

Please ask further support questions elsewhere, this is not a bug.

Ya know, if the session_name() was the only problem, and the session_name() is by default globally always "PHPSESSID", then why would simply opening up a new internet explorer browser window manually and loading myscriptB.php into it NOT have that behavior?  I'll tell you why, cause its a combination of both the session_id and the session_name needing to be different.

Clearly, the PHP documentation doesn't spell this out in any detail, and so I will be submitting a request to them to add some description of how to correctly start a new session and abandon any old or inherited one for that window.

That's not an easy, intuitive, or simple concept that any old programmer would catch right away --- that two seperately opened windows would have their own unique session_id, and therefore the common PHPSESSID name wouldn't matter, whereas spawning a child window through an <a href> tag would copy over the default session_id and so the only way to diffrentiate in that case is to change not only the session_id but the default session_name as well.

You almighty PHP gods clearly knew that, since you responded to me by saying "so of course the last accessed script..."  Us lowly PHP minions though aren't as well versed in all the ins and outs.  Reading less than clear documentation on the subject, as well as posting the same question to several different forums, and having NOONE that understood that quirk, clearly it appeared to me to be unexpected behavior, ie A BUG.

I apologize for so severely wasting your time. I wish at first glance someone might have read a little closer my original post (cause my omission was clear and obvious then) and pointed it out, instead of taking the easy way out and just blaming it on my older version of PHP. That was by beef in the the first place, that it didn't appear to be version related, and I was right.  It's your bad handling that escalated this discussion beyond a simple support open-and-close case.

Your collective self-righteous and condescending attitude doesn't help anyone here. You can't possibly expect that every single USER of PHP would be so well versed in all the insides of PHP, like looking at session files and cookies and doing traces, etc.  People of all different levels of knowledge come to the PHP website, and its several different tools, FOR SUPPORT.  I guess you assume otherwise since we don't really buy PHP like we would a product from microsoft.  That doesn't just let you off the hook, free to be rude and unhelpful to those that are genuinely seeking assistance.

The bug reporting tool is clearly focused on documenting unexpected or buggy behavior and trying to find out the solution to it.  The trouble is that you feel your job is not support in any sense, and so you assume initially that every post here is BOGUS until we the inexperienced find a way to prove otherwise.  "Guilty until proven innocent".  Very poor public relations skills on all your parts.

It's rude to make someone feel it was a huge inconvenience  that they stumbled (incorrectly) into the bug reporting tool for this problem (when its clear and logical that given the info and documentation I had it SEEMED like a bug). All you had to do was politely point out my ommission and get me in the right direction.

I was wrong, it wasn't a bug. But you were wrong, it wasn't version related either.  I have a solution now, and I'm wiser for the wear. But I have lost all respect for your team because of your poor people skills handling.  I'll tell you what's really "Bogus" around here, its your credibility.

Actually, the fact that you don't buy PHP gives us all the freedom in the world to be rude and unhelpful.  Compare the result of all this with you having submitted a bug report to Microsoft.  They would have politely ignored you.  We rudely solved your problem within 24 hours.  Which would you rather have?  You are in no position to complain here and I would advise you to stop flaming the hands that feed you.

even you using other language like micro$oft' ASP, you also
will get the same result. So no blaming to php, as rasmus
said "Do a little bit of homework please and give us
something to go on."

Just for the record, and for posterity who might read this thread and wonder, the solution was to change both the session name AND the session id BEFORE calling session_start() in the first script loaded into the new window. Thereafter in that new window (popup), before each call to session_start(), you only have to change the session name (otherwise it will default back to the "PHPSESSID").

This gave me the results I expected, the problem really was that it was not a correctly documented process, and so it appeared to be a bug at first. I have since submitted this to the documentation team to have them consider clarifying their documentation.

the ice caps are melting, nyah nyah nyah




the world is drowning, nyah nyah nyah