ID: 8989 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Windows NT 4 SP5(IIS4)/2000 SP2 PHP Version: 4.0.6 New Comment:
My bad. Tried to use RC provided in the URL again. Decompressed .ZIP file to single directory and configured webserver to use that. Last time I tried to make the directory structure match previous point releases (the dir structure I listed in a previous post). I have not worked with RCs before and didn't realize everything was compiled in such a way that it NEEDS to be all together vs. structure as defined by PHP.INI. Long story short, YES the session bug is still with us. Please note I am still working with the CGI version at this point. I have not tried testing the IIS or Apache modules. But as for the Windows CGI version of PHP v4.1.0RC3, YES, the bug is still in there. Session file creation is the same as it has been with all releases back through and including v4.0.4. Within what should be a single session, new 0 byte files are generated as before, resulting in session variables losing their values. The moment I reset things to PHP v4.0.3pl1 configuration, everything works as it should. Switch to the RC, and it's a problem. Does not matter which webserver you use (no surprise considering this is the CGI version). If there is anything else I can do, please advise. Previous Comments: ------------------------------------------------------------------------ [2001-11-24 22:57:50] [EMAIL PROTECTED] Apologies. Re-read my last post and where I wrote "I realize this is a release compilation" I meant to write "I realize this is only a release candidate compilation" (as opposed to a full release for public consumption). Sorry for any confusion. ------------------------------------------------------------------------ [2001-11-24 22:55:01] [EMAIL PROTECTED] I downloaded the latest Windows RC build at the link provided, but there appears to be an issue with the CGI version. Took me a few minutes to track it down, but in the end went to a command line and tried to do a simple php -v to get a version number. Instead, I received a popup window saying "The dynamic link library MSVCRTD.dll could not be found in the specified path..." with my PATH environment variable's value following. When I did the same command to the older CGI php.exe (v4.0.3pl1), it worked like a champ. This RC appears to be compiled differently than release versions, requiring a DLL that the release versions never have. I realize this is a release compilation. The contents of the .ZIP file were not organized in the usual tree structure previous Windows versions had / +---/browscap +---/dlls +---/extensions +---/mibs +---/sapi But just working at the command line I should be able to get a response to the '-v' switch. So unfortunately I am, at this time, unable to work with the latest Windows RC provided at the link from the previous post. Though I appreciate that you "can not reproduce this in Linux with latest CVS", please understand this bug report concerns the Windows version of PHP. I suspect this has not been an issue in the *nix release of PHP for some time, or I'm sure I would have read more about it by now. The CGI version of PHP v4.0.3pl1 is still, at this point, the last properly working release for the Windows platform (and that was released a good bit ago). I suspect most users running PHP under Windows do not make use of PHP4's session features, but likely rely more on things like PHPLIB, which handle sessions in their own way (using cookies & header() calls). Currently (as of the v4.0.6 release) I have been able to reproduce, without fail, this bug under Windows NT4 (SP5 & SP6), Windows 2000 (SP1 & SP2), and even Windows XP. If there is another compiled copy of the latest RC that has been compiled in the same fashion as a release version (and ideally, with all the DLLs, etc., in the release directory structure format), please let me know and I will try again. Thanks. ------------------------------------------------------------------------ [2001-11-24 19:19:08] [EMAIL PROTECTED] Latest RC build can be found here: http://phpuk.org/~james/php-4.1.0RC3-win32.zip And I can not reproduce this in Linux with latest CVS. --Jani ------------------------------------------------------------------------ [2001-11-19 12:56:00] [EMAIL PROTECTED] Is there any way to obtain the latest PHP release candidates in binary form for the Windows platform? I would like to test the latest RC for this bug, but I forgot that the PHP site doesn't provide binaries for RCs, and I unfortunately do not have the dev tools needed under Windows to compile the source. Otherwise, I will only be able to test the next version when it is released. ------------------------------------------------------------------------ [2001-11-18 13:34:59] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ 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]
