Bug #8989 Updated: Bug#5493 resurfaced
| From: | fseesink at usa dot net | Date: | Fri, 15 Jun 2001 15:08:43 +0000 |
| Subject: | Bug #8989 Updated: Bug#5493 resurfaced | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-56836@lists.php.net to get a copy of this message | ||
ID: 8989
User Update by: fseesink@usa.net
Old-Status: Feedback
Status: Open
Bug Type: *Session related
Operating system: Windows NT 4 SP5/IIS4
PHP Version: 4.0.4pl1
Description: Bug#5493 resurfaced
I have not tried the latest snapshots. I tend to wait for point releases to retest. Unfortunately
I do not have that much time to keep retesting with the nightly builds, etc. When 4.0.6 is
released, I will test with that.
Previous Comments:
---------------------------------------------------------------------------
[2001-06-14 23:18:19] sniper@php.net
Does this happen with latest snapshot from
http://www.zend.com/snapshots/ ??
There have been some fixes regarding this.
--Jani
---------------------------------------------------------------------------
[2001-06-07 23:45:32] fseesink@usa.net
Note I have not tested the ISAPI modules in the last few releases, so I cannot state whether they
work or not. I only know that the CGI modules since v4.0.3pl1 are again demonstrating a failure to
properly store session files.
In the past it seemed that the CGI module's development was performed first, then the ISAPI
module. I got tired of having issues with the ISAPI module and decided for the duration to stick to
just using the CGI module.
If that trend has somehow reversed or if the ISAPI module is now on par with the CGI module both
stability and functions-wise, then please let me know. I would like to switch over to the ISAPI
module as it supposed to offer increased performance. However, I will take stability over
performance any day.
---------------------------------------------------------------------------
[2001-06-07 23:41:34] fseesink@usa.net
Yes, the problem still exists in the v.4.0.5 CGI module. PLEASE resolve this issue if possible, as
I am still forced to use v4.0.3pl1 if I wish to use PHP4 session variables.
This bug was resolved and session variables working up thru v4.0.3pl1. With every release since,
however, this problem has persisted once again.
---------------------------------------------------------------------------
[2001-05-22 21:11:37] sbergmann@php.net
Does this problem persist with a recent version of PHP 4 (like latest CVS or PHP 4.0.5)?
---------------------------------------------------------------------------
[2001-01-29 18:06:15] fseesink@usa.net
v4.0.4pl1 CGI version, with or without v1 of Zend Optimizer,
is once again demonstrating similar session file generation
as I reported earlier in BUG #5493. It looks like an old
bug has snuck back in the code.
I believe BUG #8912 also relates to same issue. Note I have
not yet tested the ISAPI module.
Using the same script as in BUG #5493, I am now seeing
similar, though not the same activity. Firing up a new
browser, here is what I am seeing as I load the pages
Page1.PHP thru Page4.PHP IN ORDER:
1. Page1 creates sessionid file
2. Page2 updates initial file fine
3. Page3 -"-
4. Page4 creates new sessionid file (size 0 bytes, as will
be all sessionid files from this point on). From this point
on, we will never get valid session data again, just as
before with this bug.
5. Page1 creates new sessionid file
6. Page2-3 no new file
7. Page4-1 create new files
8. Page2-3 no new file
9. Page 4-1 create new files
10. Page2 no new file
11. Page3-4 create new files *PATTERN CHANGE
12. Page1-2 no new file
13. Page3-4 create new files
14. ***Steps #12-13 repeat 5x ***
15. Page1 creates new file
16. Page2-3 no new file
17. Page4 new file
The pattern seems to fluctuate back and forth between
Page4-1 creating new sessionid files and then Page3-4
creating sessionid files.
I suspect whatever was at the root of BUG #5493 will likely
be the cause here as well.
---------------------------------------------------------------------------
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