ID: 8989
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *Session related
Operating system: Windows NT 4 SP5(IIS4)/2000 SP2
PHP Version: 4.0.6
Description: Bug#5493 resurfaced
Configured Win2K/IIS5 for PHP v4.0.6 ISAPI module.
Took appropriate steps to shutdown & restart server (net stop iisadmin, net start
w3svc). Issue exists in ISAPI module as well.
Then configured same box for PHP v4.0.3pl1 ISAPI module. Same problem exists there as
well.
The last version of PHP that performs sessions correctly under Windows is the
v4.0.3pl1 CGI edition. If you can find others to validate that newer versions work
properly using the script I provided, I'm open to suggestions. I had this issue under
Windows NT4/IIS4, now still with Win2K/IIS5. I do not believe it to be an isolated
case.
If anyone else is reading this bug report experiencing similar problems, please post
so the developers will know.
Previous Comments:
---------------------------------------------------------------------------
[2001-07-02 14:30:28] [EMAIL PROTECTED]
Configured Windows 2000/IIS 5 webserver with PHP v4.0.6 CGI (disabled Zend Optimizer,
etc.). Tried accessing the page1.php-page4.php test I provided earlier. Used
Netscape v4.77 & IE 5.5SP1 for Windows 2000, as well as Konqueror 2.1.1 & Netscsape
4.76 under KDE on Red Hat Linux 7.1. All browsers have cookies enabled.
In all cases, initial session file is created with variable values stored properly.
But as you move through the pages, new session files are generated (effectively
different session IDs), with all session files after the 1st being 0 bytes. In short,
session not maintained.
Again, this issue existed prior to PHP v4.0.2. The Windows version of PHP CGI v4.0.2
- v4.0.3pl1 (the latter being what I still use today) all performed properly. With
v4.0.4, problem resurfaced and has remained.
I don't know if there is a way to see what changes were made from 4.0.1pl1 -> 4.0.2
and then 4.0.3pl1 -> 4.0.4 and if any changes were accidentally undone.
---------------------------------------------------------------------------
[2001-07-02 00:39:36] [EMAIL PROTECTED]
>1. Only person using hostile tone around here is you.
Do you even READ what you write and consider how it sounds? I disagree with your
opinion, but no point discussing it with you. Let's just stick to bug hunting.
>2. This is a BUG database, not a discussion forum.
Good point. That's why I posted here what I wrote for both this problem and its
earlier incarnation, #5493. And if you bothered to read the postings, you would've
found all the answers to your questions.
I didn't post a bug with the idea to have the bug dismissed without validation, as
#5493 was (by you as well, sniper). And to point out something, I only became aware
of this last post of yours when I visited the website. I was NOT sent an e-mail of
this last post. This is exactly how #5493 died. I only learned of it later. Luckily
I decided to check the site, or this problem may have died as the last...without
proper resolution.
>3. Did you or did you not try my short example script??
> Does the number get higher or does it always give you an
> error message when you reload the page?
Oops, that one IS my goof. I looked at my last post and saw that I didn't spell it
out very well.
Yes, I ran your example script.
Yes, the number gets higher.
But again, this is NOT what the bug report was about.
>4. Is the session cookie set at all? Does this happen with any
> browser?
Yes, the session cookie is set initially. In your example script, it works fine. In
my example scripts, new session files are generated over time as you cycle thru the
links. See bug #5493 for more details.
The only browsers I have handy are IE 5.5SP1 & Netscape 4.77 running on Windows 2000.
I'll double-check in the morning, but I believe it occurs regardless of browser. Will
see if I can get confirmation from other browsers such as Konqueror. May take a day
or two.
>5. What is the value for register_globals in your php.ini?
register_globals = ON
FINAL NOTES:
1. On http://www.php.net/bugs.php displayed all OPEN bugs of type SESSION RELATED.
Problem #8989 was not listed. Should this be reported as a separate problem with the
site, and if so, what is the appropriate category? (Display done multiple times with
same result.)
2. Last posting
"[2001-06-27 11:26:13] [EMAIL PROTECTED]"
was NOT e-mailed to me by the system. Again, should this be reported as a separate
problem with the site, and if so, what is the appropriate category? I would like to
make sure I receive your postings so that I can be sure to reply in a timely manner.
---------------------------------------------------------------------------
[2001-06-27 11:26:13] [EMAIL PROTECTED]
1. Only person using hostile tone around here is you.
2. This is a BUG database, not a discussion forum.
3. Did you or did you not try my short example script??
Does the number get higher or does it always give you
an error message when you reload the page?
4. Is the session cookie set at all? Does this happen with any browser?
5. What is the value for register_globals in your php.ini?
--Jani
---------------------------------------------------------------------------
[2001-06-26 12:36:01] [EMAIL PROTECTED]
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, InetPubsessions). Then either open a Command Prompt to this directory or use
Explorer (whatever suits you).
4. Serving these files from IIS (say InetPubwwwroot), 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.
---------------------------------------------------------------------------
[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++;
?>
---------------------------------------------------------------------------
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]
