ID: 8989
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: *Session related
Operating system: Windows NT 4 SP5(IIS4)/2000 SP2
PHP Version: 4.0.6
Description: Bug#5493 resurfaced
That's very nice. But that is not what this bug report was about.
PHP v4.x has always been able to initially create a session variable. The challenge
is NOT within a single page. The problem, as clearly described in earlier postings of
both this problem and an earlier problem (see #5493 for source used), is the
maintenance of session variables BETWEEN pages...the whole POINT of using session
variables (i.e., maintaining state, vs. the stateless nature of HTTP). And note,
before giving another trite example, that I provided source for you to use. But just
in case you did not read this actual problem in its entirety, here's the breakdown
once more:
1. Create the file page1.php as follows:
__________________________________________________
<?
session_start();
if (!$PHPSESSID) {
$userid=100;
$firstaccess=time();
$lastaccess=time();
session_register("userid");
session_register("firstaccess");
session_register("lastaccess");
}
$lastaccess = time();
?>
<HTML>
<HEAD>
<TITLE>Page 1</TITLE>
</HEAD>
<BODY>
This is page 1.<br>
<?
echo "\$PHPSESSID = '$PHPSESSID'<br>";
echo "\$userid = '$userid'<br>";
echo "\$firstaccess = '$firstaccess'<br>";
echo "\$lastaccess = '$lastaccess'<p>";
?>
<A HREF="page2.php">Page 2</A>.<p>
</BODY>
</HTML>
__________________________________________________
2. Create files page2.php, page3.php, & page4.php, copying the code above. The only
changes that needs to be made are to change the <TITLE> for each file as appropriate,
the one line (though this was superflous), and the <A HREF> tag so that essentially
PAGE1.PHP -> PAGE2.PHP -> PAGE3.PHP -> PAGE4.PHP -> PAGE1.PHP
thus creating a loop that cycles around the 4 pages.
3. Make sure the PHP.INI file is properly configured to store session files (for this
example, \InetPub\sessions). Then either open a Command Prompt to this directory or
use Explorer (whatever suits you).
4. Serving these files from IIS (say \InetPub\wwwroot), load page1.php.
5. Look in the session directory. You should see a session file created. Note its
size (60 bytes in this case).
6. Now start clicking on the link on page1.php. This will load page2.php, which
shows the current value of the session ID. Keep clicking on the links and keep
watching the session directory.
What you will find is that new session files are being created, session files that are
0 bytes and contain NOTHING. This is a serious problem. It's makes session
management useless in PHP under Windows.
Hopefully it's isolated to just the Winblows world using IIS. Unfortunately, that's
the environment I work in, and since PHP is offered, I provide feedback and bug
reports whenever I run into such problems.
Maybe I come across as a bit brusk, but truth be told, the manner in which you write,
sniper, demonstrates at best a lack of tact and awareness of the impact your choice of
words has, and at worst it demonstrates a serious lack of social skills and a
beligerent nature not conducive to software development. Each time you write you
indicate that you haven't bothered to READ the bug report and really know what the
problem is. I think I've done a reasonable job of detailing EXACTLY how to duplicate
what I have done. I did not just write "Sessions suck. Fix it." If you had read it,
you might not have written that last response.
I realize this is an open source project, and PHP, like Apache and all other such
projects rely on the hard work of many committed people who sacrifice time, energy,
and effort to make it the best damn server side scripting language I've seen. It's
clean, it runs well, and (except for this bug which was squashed, then resurfaced and
has persisted through 4 revisions now) is pretty rock solid. And so don't
misunderstand. I do sincerely appreciate all the time/energy/effort/etc. you and
everyone on the PHP team put forth.
However, the tonality of your words in repeated messages has come across as
beligerent, compative, hostile, and appears based on a lack of understanding of the
bug report. Maybe that is not truly the case. Maybe you're just a damn fine
programmer but suck at writing skills. We all have our strong & weak points. But the
words you have chosen, and the comments you have put forth (like the last message
which really shows you misunderstand the bug being reported) don't exactly endear you.
And this appearance of being hostile is NOT something anyone, including myself,
should have to tolerate when all I am trying to do is help you to pinpoint a bug so
you can fix it.
So, with that said, let's see if we can't put this bug to bed once and for all.
That's what this is all about, isn't it? Working together against a common foe: the
software bug.
Previous Comments:
---------------------------------------------------------------------------
[2001-06-26 06:24:41] [EMAIL PROTECTED]
PHP 4.0.6 works very nicely for me as CGI.
Try this short script:
<?php
error_reporting(E_ALL);
session_start();
session_register('myvar');
if(!isset($myvar)) $myvar = 0;
echo $myvar++;
?>
---------------------------------------------------------------------------
[2001-06-25 13:57:47] [EMAIL PROTECTED]
PHP v4.0.6 is now out. I have installed and run v4.0.6. I have tried running it
leaving the PHP4TS.DLL from v4.0.3pl1 in place (since the installation instructions
now read
"...Some DLLs are required for some PHP extensions. Please copy them to your to your
windows/system (Win9.x) or winnt/system32 (WinNT, Win2000) directory. IF YOU ALREADY
HAVE THESE DLLS INSTALLED ON YOUR SYSTEM, OVERWRITE THEM ONLY IF SOMETHING IS NOT
WORKING CORRECTLY [emphasis added]...."
The problem still existed, so I dropped the PHP4TS.DLL file that came with PHP v4.06
and tried again. Same problem.
The CGI version of PHP v4.0.6 STILL has the same problem. Once again, for proper
session work, I have to stay at v4.0.3pl1, the LAST version that did session variables
properly.
Can we re-open this now? Thank you.
---------------------------------------------------------------------------
[2001-06-19 17:55:13] [EMAIL PROTECTED]
Amazing. No report has been made that the bug has been resolved, yet you have a burr
up your butt to close out the problem anyway. Great debugging technique. Truly
professional. Good to know PHP is in such good hands.
Yes, to answer your comment, I DO remember that I wrote that. In fact, it's basically
a repeat of the same thing I wrote earlier, since you did not seem to pay attention
the first time. Each time a point release is out, I check it, as I--like many PHP
users--would like to have the latest features and bug fixes. PHP totally kicks ass,
but unfortunately there are some glitches from time to time.
HOWEVER, a nightly CVS build is not considered by most to be a stable release. Ergo
we have such things as RELEASE CANDIDATES. PHP is now at 4.0.6 RC3 if memory recalls
correctly. However, this too is not a full release. RCs are basically like beta
releases for those so inclined (and with sufficient time) to be guinea pigs. CVS
nightly builds are for those normally heavily involved, RCs are for those who want to
help point out flaws in the next release, and then actual point releases are what most
users obtain.
I apologize if I don't satisfy your sudden demand for people to jump at testing your
nightly builds or RCs. But like many I actually have a job and life that requires
most of my time. I gladly test full point releases, but unfortunately do not have
time to be your daily minion.
This is the first time I've witnessed anyone involved with PHP development act in such
a manner. I hope it's not a sign of things to come.
---------------------------------------------------------------------------
[2001-06-19 16:45:30] [EMAIL PROTECTED]
Do you remember this:
> I have not tried the latest snapshots. I tend to wait for point releases to re
> test.
> Unfortunately I do not have that much time to keep retesting with the nightly b
> uilds, etc.
> When 4.0.6 is released, I will test with that.
Then reopen this report when it is not fixed in 4.0.6.
period
---------------------------------------------------------------------------
[2001-06-19 10:56:24] [EMAIL PROTECTED]
What is this, the Microsoft approach to dealing with bugs? You have no evidence if
the problem is resolved, yet you close out the problem anyway. Burying your head in
the sand doesn't make the issue go away.
I'm sorry, but you don't close a problem until a resolution is found and the fix
confirmed. There is a session bug, which existed in early 4.0 releases, was then
fixed, and is now broken again. The last working version of PHP for Windows that did
sessions properly was 4.0.3pl1, and nothing thus far indicates that this issue has
been resolved since then.
I have updated the PHP Version for you to reflect the problem still exists in 4.0.5,
the latest release most users would touch. Most PHP users are not about to touch
nightly CVS builds. That's why you HAVE point releases like 4.0.3pl1, 4.0.4, 4.0.5,
etc.
This problem should remain open until it can be confirmed that the bug is fixed.
---------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
Full Bug description available at: http://bugs.php.net/?id=8989
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
