ID: 23764
Comment by: heng at yahoo dot com
Reported By: mfoxx at hotmail dot com
Status: Bogus
Bug Type: Session related
Operating System: RH 6.2
PHP Version: 4.3.0
New Comment:
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."
Previous Comments:
------------------------------------------------------------------------
[2003-05-23 11:32:10] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[2003-05-23 11:21:59] mfoxx at hotmail dot com
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.
------------------------------------------------------------------------
[2003-05-23 10:09:48] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[2003-05-23 09:22:33] mfoxx at hotmail dot com
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.
------------------------------------------------------------------------
[2003-05-22 20:30:40] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23764
--
Edit this bug report at http://bugs.php.net/?id=23764&edit=1
