|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2001-01-29 18:06 UTC] fseesink at usa dot 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. PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Mon May 05 23:01:28 2025 UTC |
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++; ?>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.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.