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:
Thanks to the kind help of one H C Teo in Singapore, I believe I have found the source of the problem to this bug! H C Teo was kind enough, upon reading this bug report, to contact me directly via e-mail to let me know that someone DID have sessions working properly under Windows using my example code. H C Teo's configuration consisted of both Windows 98 and Windows 2000 SP2 running the Xitami webserver using the CGI version of PHP v4.0.6. H C Teo not only ran sniper's test (which ran fine for me as well, but did not demonstrate the bug which my code showed), but also--and I'm very grateful that someone took the few minutes to do this--took MY example files and ran them. My files worked for H C Teo as well! Considering it was the same OS and we both use the CGI version of PHP (which makes the webserver irrelevant in most cases), the problem must be elsewhere. Once again H C Teo came thru by providing access to the info provided in phpinfo(). I compared this to my configuration, noticed entries missing from my configuration that H C Teo had, and then it hit me: the PHP.INI file! I have been using PHP4 since it first came out, and my PHP.INI file dates back to around v4.0.1. As mentioned in this bug report, this bug first appeared in earlier releases (bug#5493), then disappeared in 4.0.2 - 4.0.3pl1, then resurfaced in 4.0.4. I have not changed my PHP.INI file in all that time. But what if I started COMPLETELY from scratch? I deleted the \WINNT\SYSTEM32\PHP4TS.DLL and \WINNT\PHP.INI files (making a backup of course). Then I installed PHP 4.0.6 cleanly, making ONLY the changes suggested in the installation instructions. [Note the installation instructions do NOT ever suggest that you need to rebuild your PHP.INI file with each release.] Sessions WORKED! After this, I compared my old PHP.INI file to the new one, and long story short, here's what I found. The problem appears to be with the following entry in the PHP.INI file: ____________________________________________________________ ... ; Check HTTP Referer to invalidate externally stored URLs containing ids. session.referer_check = ... ____________________________________________________________ The default for this entry is empty. If left this way PHP 4.0.6 does sessions properly. However, if you attempt to turn on this feature by setting the entry to '1' or 'On' (without the quotes), sessions do not work properly. New, empty session files are generated over time using the sample code I provided. I can only suspect that the issue has to do with some failure in the PHP engine to properly determine the source of a webpage. Since all my sample pages are hosted on the same webserver, this referrer check should not fail, but considering this feature's intended purpose, in the event someone WAS spoofing a page, it makes sense that a new session file would be created. But that's not the case here. Ergo, I believe we now have the proper focus for this bug report. Please investigate the session.referer_check feature in PHP for Windows. It does not appear to be functioning properly. Also, for future reference, you may wish to suggest to those posting bug reports to try running the default PHP.INI configs provided with PHP, making only the minimalist changes needed to get PHP working. If the problem disappears, at least you have a place to go to track down the problem. No one ever suggested trying a clean PHP.INI file to me. This would have saved me untold aggravation and helped track down this issue much sooner. Regardless, thanks to everyone involved, especially H C Teo, without whom I'd still be running PHP 4.0.3pl1. Though I had to turn off a feature to do so, I am now happily running PHP 4.0.6, and I'm looking forward to the release of 4.1.0!!! P.S. Please do not forget to investigate the session.referer_check setting. It would be nice to have this working. Thanks. Previous Comments: ------------------------------------------------------------------------ [2001-11-26 20:06:57] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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]
