ID: 8989
User updated by: [EMAIL PROTECTED]
Reported 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
New Comment:
You can find the example script I provided in the posting to this problem dated
[2001-06-26 12:36:01], but here is the relevant portion to save you time:
Note PHP v4.x has always been able to initially create a session variable. The
challenge is NOT within a single page that the problem arises. The problem, described
both here and in an earlier problem (#5493), is the maintenance of session variables
BETWEEN pages. So...
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 need to be made are to change
* the <TITLE> for each file (optional really)
* the one line reading "This is page 1" (also optional really, but both help you to
see the page transitions), and
* the <A HREF> tag (this is important) so that essentially the links cause
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, as it makes session
management useless in PHP under Windows.
As for the latest release candidate of PHP v4.1.0, I will download that as soon as I
have some free time and see whether the issue has been resolved. Please note, as
stated earlier in this problem, that this issue existed with earlier versions of PHP
but was resolved up to v4.0.3pl1 (CGI version only). Then it resurfaced and has been
part of PHP up and including v4.0.6. Due to this, I am still using PHP v4.0.3pl1 at
this time.
Also note that with the latest rash of IIS vulnerabilities, I am moving from IIS
towards Apache. If I can, I will try to run the latest RC under both webservers. But
thus far, since I tend to stick to the CGI version under Windows, the webserver used
has made no difference. The issue exists under both IIS and Apache.
Previous Comments:
------------------------------------------------------------------------
[2001-11-18 01:21:49] [EMAIL PROTECTED]
Please provide either a script to reproduce your problem with or grab the latest PHP
4.1.0 release candidate and test it yourself. Thanks for your help.
------------------------------------------------------------------------
[2001-08-23 12:30:16] [EMAIL PROTECTED]
Any update on the PHP session problems in v4.0.4+? I've received several e-mails from
people saying they're experiencing similar results, but apparently they can't post to
this problem. Just curious. It's been a couple of months, so thought I'd ask.
Also, any way for people to still get a copy of PHP v4.0.3pl1? I've had a few ask me,
and noticed php.net only goes back to 4.0.4 now.
------------------------------------------------------------------------
[2001-07-02 15:01:16] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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/?id=8989
Edit this bug report at http://bugs.php.net/?id=8989&edit=1
--
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]
