PHP 4.0 Bug #5493 Updated: Both ISAPI & CGI modules in 4.0.1pl2 exhibit errors with session ids

ID: 5493 User Update by: fseesink@usa.net Status: Open Bug Type: Session related Description: Both ISAPI & CGI modules in 4.0.1pl2 exhibit errors with session ids More debug info regarding PHP v4.0.1pl2. I have now tested the errors I have encountered on two different PCs, both running Windows NT Server 4 SP5 with IIS4. The configs as far as file locations are slightly different: PC#1 (both D: & E: are NTFS) ---- D:\WINNT - drive system installed on E:\InetPub\wwwroot - root of website E:\InetPub\wwwroot\php - where PHP scripts located E:\InetPub\wwwroot\php\sessions - where Page1.PHP, Page2.PHP, etc. located E:\InetPub\sessions - directory where PHP.INI pointed to store session ID files PC#2 (D: is NTFS) ---- D:\WINNT - drive system installed on D:\InetPub\wwwroot - root of website D:\InetPub\wwwroot\php - where PHP scripts located D:\InetPub\wwwroot\php\sessions - where Page1.PHP, Page2.PHP, etc. located D:\InetPub\sessions - directory where PHP.INI pointed to store session ID files Interestingly enough, on PC#2 the CGI error of "Warning: open(/tmp/sess_f30188520bcdfb68ecd0baf4236475b7, O_RDWR) failed" did not occur. HOWEVER, one consistent error that I have been able to reproduce on BOTH PCs and that cause the same sequence of errors while using the ISAPI module is the following: 1. Fire up a new browser (to make sure no PHPSESSIDs are set). 2. Load Page1.PHP. The output of this page does not show a PHPSESSID value as it has been setup but not yet transmitted to the client as a cookie. Checking .\sessions directory shows a sessionid file has indeed been created and variable values stored. 3. Click on the Page 2 link to load Page2.PHP. Now the sessionid created by Page1 is shown and all seems right with the world. Checking .\sessions shows that indeed just one sessionid file exists and $lastaccess updated properly in file. 4. Click on the Page 3 link to load Page3.PHP. Now the madness begins. No longer showing values for $userid or $firstaccess, the page still shows the initial sessionid. HOWEVER, looking in .\sessions shows that a NEW sessionid file has been created (0 bytes). $lastaccess is updated on the page but not in the sessionid file. 5. Clicking on Page 4 link to load Page4.PHP, we now find the session id shown is that of the 2nd sessionid file created. $userid & $firstaccess remain empty, $lastaccess is updated on page but not in a session file, and in .\sessions we find yet ANOTHER session id file (0 bytes). 6. Clicking on Page 1 link to return us to Page1.PHP, we now see the session id of the file created when loading Page 4, $userid & $firstaccess remain empty, and yet another session id file is created (0 bytes) in .\sessions. 7. Clicking on Page 2 link to load Page2.PHP a second time, interesting thing happens. Just as the first time around, Page2.PHP now shows the sessionid of the file created when loading Page1.PHP (this is the second sessionid created by Page1.PHP, mind you, not the original). $userid & $firstaccess remain empty, but NO NEW SESSION FILE CREATED! 8. Clicking on Page 3 link to load Page3.PHP, we now see the same session ID that we just saw on Page2.PHP, $userid & $firstaccess will remain forever empty, and now once again a new session file (0 bytes) is created in .\sessions. This pattern repeats itself over and over again. All the pages except Page2.PHP cause new session id files to be created through each iteration of the loop. Go figure. I hope this helps the PHP engine coders out there. Between this and the various issues I have encountered trying to work with setting cookies & headers, I so far am finding PHP4 to be less than usable. I've had nothing but frustration attempting to do setcookie(), header() and session_start() in the same file...and no, there's no other output prior to these calls. The errors do not involve the "header has already been sent" message.. In many cases the cookies simply refuse to be set at all. Newbies will get quickly frustrated, thinking they do not understand when in fact it is the engine that is failing them. At least on the IIS side of life. Yeah yeah, I know, I should use Apache, etc., but right now it's what I'm stuck with. But being open source and grammatically well-designed, PHP is the only scripting language I will use. Full Bug description available at: http://bugs.php.net/?id=5493