[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Session related Operating System: Windows NT 4 SP5(IIS4)/2000 SP2 PHP Version: 4.0.6 New Comment: Thanks for all the help, guys, and especially H C Teo for giving me the comparison to work with that led to finding where the problem was. Namely, in the PHP.INI setting I had. After sniper's last post (thanks, by the way, for adding a note to the php.ini-dist and php.ini-recommended files...I hope it helps others avoid what happened to me), I followed the link, did a search on session.referer, and found the post from [EMAIL PROTECTED] on 08-Aug-2000 03:09, which describes the EXACT symptoms I was having. Of course, before this past week, I had no idea that it was a setting in PHP.INI that caused this. Ah well, hindsight is 20/20. *sigh* Thanks again, everyone. I am a VERY happy camper now. Previous Comments: [2001-12-04 19:32:36] [EMAIL PROTECTED] http://www.php.net/manual/en/ref.session.php session.referer_check contains the substring you want to check each HTTP Referer for. If the Referer was sent by the client and the substring was not found, the embedded session id will be marked as invalid. Defaults to the empty string. I added a note into php.ini-dist and php.ini-recommended about this value being a substring. --Jani [2001-12-02 01:34:29] [EMAIL PROTECTED] 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
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
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
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
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
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Session related
Operating System: Windows NT 4 SP5(IIS4)/2000 SP2
PHP Version: 4.0.6
New Comment:
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
Previous Comments:
[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
TITLEPage 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.phpPage 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.
[2001-11-18 01:21:49] [EMAIL PROTECTED]
Please provide either a script to reproduce your problem with or grab the latest PHP
4.1.0 release candidate and test it yourself. Thanks for your help.
[2001-08-23 12:30:16] [EMAIL PROTECTED]
Any update on the PHP session problems in v4.0.4+? I've received several e-mails from
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Session related
Operating System: Windows NT 4 SP5(IIS4)/2000 SP2
PHP Version: 4.0.6
New Comment:
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.
Previous Comments:
[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
TITLEPage 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.phpPage 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
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
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:
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.
Previous Comments:
[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
TITLEPage 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
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
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:
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.
Previous Comments:
[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
TITLEPage 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.phpPage 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.
[2001-11-18 01:21:49] [EMAIL PROTECTED]
Please provide either a script to reproduce your problem with or grab the latest PHP
4.1.0 release candidate and test it yourself. Thanks for your help.
[2001-08-23 12:30:16] [EMAIL PROTECTED]
Any update on the PHP session problems in v4.0.4+? I've received several e-mails from
people saying they're experiencing similar results, but apparently they can't post to
this problem. Just curious. It's been a couple of months, so thought I'd ask.
Also, any way for people to still get a copy of PHP v4.0.3pl1? I've had a few ask me,
and noticed
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Session related
Operating System: Windows NT 4 SP5(IIS4)/2000 SP2
PHP Version: 4.0.6
New Comment:
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
TITLEPage 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.phpPage 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.
Previous Comments:
[2001-11-18 01:21:49] [EMAIL PROTECTED]
Please provide either a script to reproduce your problem with or grab the latest PHP
4.1.0 release candidate and test it yourself. Thanks for your help.
[2001-08-23 12:30:16] [EMAIL PROTECTED]
Any update on the PHP session problems in v4.0.4+? I've received several e-mails from
people saying they're experiencing similar results, but apparently they can't post to
this problem. Just curious. It's been a couple of months, so thought I'd ask.
Also, any way for people to still get a copy of PHP v4.0.3pl1? I've had a few ask me,
and noticed php.net only goes back to 4.0.4 now.
[2001-07-02 15:01:16] [EMAIL PROTECTED]
Configured Win2K/IIS5 for PHP v4.0.6 ISAPI module.
Took appropriate steps to shutdown restart server (net stop iisadmin, net start
w3svc). Issue exists in ISAPI module as well.
Then configured same box for PHP v4.0.3pl1 ISAPI module. Same problem exists there as
well.
The last version of PHP that performs sessions correctly
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989 User Update by: [EMAIL PROTECTED] Old-Status: Closed Status: Open Bug Type: *Session related Operating system: Windows NT 4 SP5(IIS4)/2000 SP2 (IIS5) PHP Version: 4.0.6 Description: Bug#5493 resurfaced PHP v4.0.6 is now out. I have installed and run v4.0.6. I have tried running it leaving the PHP4TS.DLL from v4.0.3pl1 in place (since the installation instructions now read ...Some DLLs are required for some PHP extensions. Please copy them to your to your windows/system (Win9.x) or winnt/system32 (WinNT, Win2000) directory. IF YOU ALREADY HAVE THESE DLLS INSTALLED ON YOUR SYSTEM, OVERWRITE THEM ONLY IF SOMETHING IS NOT WORKING CORRECTLY [emphasis added] The problem still existed, so I dropped the PHP4TS.DLL file that came with PHP v4.06 and tried again. Same problem. The CGI version of PHP v4.0.6 STILL has the same problem. Once again, for proper session work, I have to stay at v4.0.3pl1, the LAST version that did session variables properly. Can we re-open this now? Thank you. Previous Comments: --- [2001-06-19 17:55:13] [EMAIL PROTECTED] Amazing. No report has been made that the bug has been resolved, yet you have a burr up your butt to close out the problem anyway. Great debugging technique. Truly professional. Good to know PHP is in such good hands. Yes, to answer your comment, I DO remember that I wrote that. In fact, it's basically a repeat of the same thing I wrote earlier, since you did not seem to pay attention the first time. Each time a point release is out, I check it, as I--like many PHP users--would like to have the latest features and bug fixes. PHP totally kicks ass, but unfortunately there are some glitches from time to time. HOWEVER, a nightly CVS build is not considered by most to be a stable release. Ergo we have such things as RELEASE CANDIDATES. PHP is now at 4.0.6 RC3 if memory recalls correctly. However, this too is not a full release. RCs are basically like beta releases for those so inclined (and with sufficient time) to be guinea pigs. CVS nightly builds are for those normally heavily involved, RCs are for those who want to help point out flaws in the next release, and then actual point releases are what most users obtain. I apologize if I don't satisfy your sudden demand for people to jump at testing your nightly builds or RCs. But like many I actually have a job and life that requires most of my time. I gladly test full point releases, but unfortunately do not have time to be your daily minion. This is the first time I've witnessed anyone involved with PHP development act in such a manner. I hope it's not a sign of things to come. --- [2001-06-19 16:45:30] [EMAIL PROTECTED] Do you remember this: I have not tried the latest snapshots. I tend to wait for point releases to re test. Unfortunately I do not have that much time to keep retesting with the nightly b uilds, etc. When 4.0.6 is released, I will test with that. Then reopen this report when it is not fixed in 4.0.6. period --- [2001-06-19 10:56:24] [EMAIL PROTECTED] What is this, the Microsoft approach to dealing with bugs? You have no evidence if the problem is resolved, yet you close out the problem anyway. Burying your head in the sand doesn't make the issue go away. I'm sorry, but you don't close a problem until a resolution is found and the fix confirmed. There is a session bug, which existed in early 4.0 releases, was then fixed, and is now broken again. The last working version of PHP for Windows that did sessions properly was 4.0.3pl1, and nothing thus far indicates that this issue has been resolved since then. I have updated the PHP Version for you to reflect the problem still exists in 4.0.5, the latest release most users would touch. Most PHP users are not about to touch nightly CVS builds. That's why you HAVE point releases like 4.0.3pl1, 4.0.4, 4.0.5, etc. This problem should remain open until it can be confirmed that the bug is fixed. --- [2001-06-19 09:27:34] [EMAIL PROTECTED] Reopen this if it doesn't work with 4.0.6. --Jani --- [2001-06-15 11:08:43] [EMAIL PROTECTED] 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. --- 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
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Session related
Operating system:
PHP Version: 4.0.6
Assigned To:
Comments:
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++;
?
Previous Comments:
---
[2001-06-25 13:57:47] [EMAIL PROTECTED]
PHP v4.0.6 is now out. I have installed and run v4.0.6. I have tried running it
leaving the PHP4TS.DLL from v4.0.3pl1 in place (since the installation instructions
now read
...Some DLLs are required for some PHP extensions. Please copy them to your to your
windows/system (Win9.x) or winnt/system32 (WinNT, Win2000) directory. IF YOU ALREADY
HAVE THESE DLLS INSTALLED ON YOUR SYSTEM, OVERWRITE THEM ONLY IF SOMETHING IS NOT
WORKING CORRECTLY [emphasis added]
The problem still existed, so I dropped the PHP4TS.DLL file that came with PHP v4.06
and tried again. Same problem.
The CGI version of PHP v4.0.6 STILL has the same problem. Once again, for proper
session work, I have to stay at v4.0.3pl1, the LAST version that did session variables
properly.
Can we re-open this now? Thank you.
---
[2001-06-19 17:55:13] [EMAIL PROTECTED]
Amazing. No report has been made that the bug has been resolved, yet you have a burr
up your butt to close out the problem anyway. Great debugging technique. Truly
professional. Good to know PHP is in such good hands.
Yes, to answer your comment, I DO remember that I wrote that. In fact, it's basically
a repeat of the same thing I wrote earlier, since you did not seem to pay attention
the first time. Each time a point release is out, I check it, as I--like many PHP
users--would like to have the latest features and bug fixes. PHP totally kicks ass,
but unfortunately there are some glitches from time to time.
HOWEVER, a nightly CVS build is not considered by most to be a stable release. Ergo
we have such things as RELEASE CANDIDATES. PHP is now at 4.0.6 RC3 if memory recalls
correctly. However, this too is not a full release. RCs are basically like beta
releases for those so inclined (and with sufficient time) to be guinea pigs. CVS
nightly builds are for those normally heavily involved, RCs are for those who want to
help point out flaws in the next release, and then actual point releases are what most
users obtain.
I apologize if I don't satisfy your sudden demand for people to jump at testing your
nightly builds or RCs. But like many I actually have a job and life that requires
most of my time. I gladly test full point releases, but unfortunately do not have
time to be your daily minion.
This is the first time I've witnessed anyone involved with PHP development act in such
a manner. I hope it's not a sign of things to come.
---
[2001-06-19 16:45:30] [EMAIL PROTECTED]
Do you remember this:
I have not tried the latest snapshots. I tend to wait for point releases to re
test.
Unfortunately I do not have that much time to keep retesting with the nightly b
uilds, etc.
When 4.0.6 is released, I will test with that.
Then reopen this report when it is not fixed in 4.0.6.
period
---
[2001-06-19 10:56:24] [EMAIL PROTECTED]
What is this, the Microsoft approach to dealing with bugs? You have no evidence if
the problem is resolved, yet you close out the problem anyway. Burying your head in
the sand doesn't make the issue go away.
I'm sorry, but you don't close a problem until a resolution is found and the fix
confirmed. There is a session bug, which existed in early 4.0 releases, was then
fixed, and is now broken again. The last working version of PHP for Windows that did
sessions properly was 4.0.3pl1, and nothing thus far indicates that this issue has
been resolved since then.
I have updated the PHP Version for you to reflect the problem still exists in 4.0.5,
the latest release most users would touch. Most PHP users are not about to touch
nightly CVS builds. That's why you HAVE point releases like 4.0.3pl1, 4.0.4, 4.0.5,
etc.
This problem should remain open until it can be confirmed that the bug is fixed.
---
[2001-06-19 09:27:34] [EMAIL PROTECTED]
Reopen this if it doesn't work with 4.0.6.
--Jani
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: *Session related
Operating system: Windows NT 4 SP5(IIS4)/2000 SP2
PHP Version: 4.0.6
Description: Bug#5493 resurfaced
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
TITLEPage 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.phpPage 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:
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989 User Update by: [EMAIL PROTECTED] Status: Closed Bug Type: *Session related Operating system: Windows NT 4 SP5/IIS4 PHP Version: 4.0.5 Description: Bug#5493 resurfaced Amazing. No report has been made that the bug has been resolved, yet you have a burr up your butt to close out the problem anyway. Great debugging technique. Truly professional. Good to know PHP is in such good hands. Yes, to answer your comment, I DO remember that I wrote that. In fact, it's basically a repeat of the same thing I wrote earlier, since you did not seem to pay attention the first time. Each time a point release is out, I check it, as I--like many PHP users--would like to have the latest features and bug fixes. PHP totally kicks ass, but unfortunately there are some glitches from time to time. HOWEVER, a nightly CVS build is not considered by most to be a stable release. Ergo we have such things as RELEASE CANDIDATES. PHP is now at 4.0.6 RC3 if memory recalls correctly. However, this too is not a full release. RCs are basically like beta releases for those so inclined (and with sufficient time) to be guinea pigs. CVS nightly builds are for those normally heavily involved, RCs are for those who want to help point out flaws in the next release, and then actual point releases are what most users obtain. I apologize if I don't satisfy your sudden demand for people to jump at testing your nightly builds or RCs. But like many I actually have a job and life that requires most of my time. I gladly test full point releases, but unfortunately do not have time to be your daily minion. This is the first time I've witnessed anyone involved with PHP development act in such a manner. I hope it's not a sign of things to come. Previous Comments: --- [2001-06-19 16:45:30] [EMAIL PROTECTED] Do you remember this: I have not tried the latest snapshots. I tend to wait for point releases to re test. Unfortunately I do not have that much time to keep retesting with the nightly b uilds, etc. When 4.0.6 is released, I will test with that. Then reopen this report when it is not fixed in 4.0.6. period --- [2001-06-19 10:56:24] [EMAIL PROTECTED] What is this, the Microsoft approach to dealing with bugs? You have no evidence if the problem is resolved, yet you close out the problem anyway. Burying your head in the sand doesn't make the issue go away. I'm sorry, but you don't close a problem until a resolution is found and the fix confirmed. There is a session bug, which existed in early 4.0 releases, was then fixed, and is now broken again. The last working version of PHP for Windows that did sessions properly was 4.0.3pl1, and nothing thus far indicates that this issue has been resolved since then. I have updated the PHP Version for you to reflect the problem still exists in 4.0.5, the latest release most users would touch. Most PHP users are not about to touch nightly CVS builds. That's why you HAVE point releases like 4.0.3pl1, 4.0.4, 4.0.5, etc. This problem should remain open until it can be confirmed that the bug is fixed. --- [2001-06-19 09:27:34] [EMAIL PROTECTED] Reopen this if it doesn't work with 4.0.6. --Jani --- [2001-06-15 11:08:43] [EMAIL PROTECTED] 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. --- [2001-06-14 23:18:19] [EMAIL PROTECTED] Does this happen with latest snapshot from http://www.zend.com/snapshots/ ?? There have been some fixes regarding this. --Jani --- 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 -- 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]
RE: [PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
I want to chime in here. The reason (IMHO) that they are asking you to test the latest release is because you are reporting a symptom of a bigger problem. They *think* that they fixed the bigger problem. However, the best way to be *sure* (like you want) -- is to have people see if the symptoms are gone. Instead of recreating every problem that people describe... they try to fix the root cause, and see if all of the related problems go away. Make sense? -Brian Amazing. No report has been made that the bug has been resolved, yet you have a burr up your butt to close out the problem anyway. Great debugging technique. Truly professional. Good to know PHP is in such good hands. Yes, to answer your comment, I DO remember that I wrote that. In fact, it's basically a repeat of the same thing I wrote earlier, since you did not seem to pay attention the first time. Each time a point release is out, I check it, as I--like many PHP users--would like to have the latest features and bug fixes. PHP totally kicks ass, but unfortunately there are some glitches from time to time. HOWEVER, a nightly CVS build is not considered by most to be a stable release. Ergo we have such things as RELEASE CANDIDATES. PHP is now at 4.0.6 RC3 if memory recalls correctly. However, this too is not a full release. RCs are basically like beta releases for those so inclined (and with sufficient time) to be guinea pigs. CVS nightly builds are for those normally heavily involved, RCs are for those who want to help point out flaws in the next release, and then actual point releases are what most users obtain. I apologize if I don't satisfy your sudden demand for people to jump at testing your nightly builds or RCs. But like many I actually have a job and life that requires most of my time. I gladly test full point releases, but unfortunately do not have time to be your daily minion. This is the first time I've witnessed anyone involved with PHP development act in such a manner. I hope it's not a sign of things to come. Previous Comments: --- [2001-06-19 16:45:30] [EMAIL PROTECTED] Do you remember this: I have not tried the latest snapshots. I tend to wait for point releases to re test. Unfortunately I do not have that much time to keep retesting with the nightly b uilds, etc. When 4.0.6 is released, I will test with that. Then reopen this report when it is not fixed in 4.0.6. period --- [2001-06-19 10:56:24] [EMAIL PROTECTED] What is this, the Microsoft approach to dealing with bugs? You have no evidence if the problem is resolved, yet you close out the problem anyway. Burying your head in the sand doesn't make the issue go away. I'm sorry, but you don't close a problem until a resolution is found and the fix confirmed. There is a session bug, which existed in early 4.0 releases, was then fixed, and is now broken again. The last working version of PHP for Windows that did sessions properly was 4.0.3pl1, and nothing thus far indicates that this issue has been resolved since then. I have updated the PHP Version for you to reflect the problem still exists in 4.0.5, the latest release most users would touch. Most PHP users are not about to touch nightly CVS builds. That's why you HAVE point releases like 4.0.3pl1, 4.0.4, 4.0.5, etc. This problem should remain open until it can be confirmed that the bug is fixed. --- [2001-06-19 09:27:34] [EMAIL PROTECTED] Reopen this if it doesn't work with 4.0.6. --Jani --- [2001-06-15 11:08:43] [EMAIL PROTECTED] 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. --- [2001-06-14 23:18:19] [EMAIL PROTECTED] Does this happen with latest snapshot from http://www.zend.com/snapshots/ ?? There have been some fixes regarding this. --Jani --- 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 -- 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] -- 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]
RE: [PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
Hello, On Wed, 20 Jun 2001, Brian Tanner wrote: They *think* that they fixed the bigger problem. However, the best way to be *sure* (like you want) -- is to have people see if the symptoms are gone. Instead of recreating every problem that people describe... they try to fix the root cause, and see if all of the related problems go away. Thank Brian you for clarifying this. I'm mostly doing too much at the same time to explain things like this, (and I guess that's also the case for Jani), so we just write small (and sometimes not-that-tact fullnotes). However, getting mad does not work either, and will mostly make things only worse. (i.e., makes us less eager to respond). About the 4.0.6 RC's. These are mostly more stable than the previous release (here 4.0.5). They are indeed not for production, but for development servers and workstations they work very nice. And yes, I do understand that not everybody can and will test nightly CVS builds, but IF they are tested, than bugs are more quicker verified, found and fixed. That is why we ask users to test RC's and nightly builds. regards, Derick Make sense? -Brian Amazing. No report has been made that the bug has been resolved, yet you have a burr up your butt to close out the problem anyway. Great debugging technique. Truly professional. Good to know PHP is in such good hands. Yes, to answer your comment, I DO remember that I wrote that. In fact, it's basically a repeat of the same thing I wrote earlier, since you did not seem to pay attention the first time. Each time a point release is out, I check it, as I--like many PHP users--would like to have the latest features and bug fixes. PHP totally kicks ass, but unfortunately there are some glitches from time to time. HOWEVER, a nightly CVS build is not considered by most to be a stable release. Ergo we have such things as RELEASE CANDIDATES. PHP is now at 4.0.6 RC3 if memory recalls correctly. However, this too is not a full release. RCs are basically like beta releases for those so inclined (and with sufficient time) to be guinea pigs. CVS nightly builds are for those normally heavily involved, RCs are for those who want to help point out flaws in the next release, and then actual point releases are what most users obtain. I apologize if I don't satisfy your sudden demand for people to jump at testing your nightly builds or RCs. But like many I actually have a job and life that requires most of my time. I gladly test full point releases, but unfortunately do not have time to be your daily minion. This is the first time I've witnessed anyone involved with PHP development act in such a manner. I hope it's not a sign of things to come. Previous Comments: --- [2001-06-19 16:45:30] [EMAIL PROTECTED] Do you remember this: I have not tried the latest snapshots. I tend to wait for point releases to re test. Unfortunately I do not have that much time to keep retesting with the nightly b uilds, etc. When 4.0.6 is released, I will test with that. Then reopen this report when it is not fixed in 4.0.6. period --- [2001-06-19 10:56:24] [EMAIL PROTECTED] What is this, the Microsoft approach to dealing with bugs? You have no evidence if the problem is resolved, yet you close out the problem anyway. Burying your head in the sand doesn't make the issue go away. I'm sorry, but you don't close a problem until a resolution is found and the fix confirmed. There is a session bug, which existed in early 4.0 releases, was then fixed, and is now broken again. The last working version of PHP for Windows that did sessions properly was 4.0.3pl1, and nothing thus far indicates that this issue has been resolved since then. I have updated the PHP Version for you to reflect the problem still exists in 4.0.5, the latest release most users would touch. Most PHP users are not about to touch nightly CVS builds. That's why you HAVE point releases like 4.0.3pl1, 4.0.4, 4.0.5, etc. This problem should remain open until it can be confirmed that the bug is fixed. --- [2001-06-19 09:27:34] [EMAIL PROTECTED] Reopen this if it doesn't work with 4.0.6. --Jani --- [2001-06-15 11:08:43] [EMAIL PROTECTED] 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. --- [2001-06-14 23:18:19] [EMAIL PROTECTED] Does this happen with latest snapshot from http://www.zend.com/snapshots/ ?? There have been some
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Session related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Reopen this if it doesn't work with 4.0.6. --Jani Previous Comments: --- [2001-06-15 11:08:43] [EMAIL PROTECTED] 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. --- [2001-06-14 23:18:19] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] Does this problem persist with a recent version of PHP 4 (like latest CVS or PHP 4.0.5)? --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8989edit=2 -- 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]
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Session related Operating system: PHP Version: 4.0.5 Assigned To: Comments: Do you remember this: I have not tried the latest snapshots. I tend to wait for point releases to re test. Unfortunately I do not have that much time to keep retesting with the nightly b uilds, etc. When 4.0.6 is released, I will test with that. Then reopen this report when it is not fixed in 4.0.6. period Previous Comments: --- [2001-06-19 10:56:24] [EMAIL PROTECTED] What is this, the Microsoft approach to dealing with bugs? You have no evidence if the problem is resolved, yet you close out the problem anyway. Burying your head in the sand doesn't make the issue go away. I'm sorry, but you don't close a problem until a resolution is found and the fix confirmed. There is a session bug, which existed in early 4.0 releases, was then fixed, and is now broken again. The last working version of PHP for Windows that did sessions properly was 4.0.3pl1, and nothing thus far indicates that this issue has been resolved since then. I have updated the PHP Version for you to reflect the problem still exists in 4.0.5, the latest release most users would touch. Most PHP users are not about to touch nightly CVS builds. That's why you HAVE point releases like 4.0.3pl1, 4.0.4, 4.0.5, etc. This problem should remain open until it can be confirmed that the bug is fixed. --- [2001-06-19 09:27:34] [EMAIL PROTECTED] Reopen this if it doesn't work with 4.0.6. --Jani --- [2001-06-15 11:08:43] [EMAIL PROTECTED] 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. --- [2001-06-14 23:18:19] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8989edit=2 -- 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]
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989 User Update by: [EMAIL PROTECTED] Old-Status: Closed Status: Open Bug Type: *Session related Operating system: Windows NT 4 SP5/IIS4 PHP Version: 4.0.5 Description: Bug#5493 resurfaced What is this, the Microsoft approach to dealing with bugs? You have no evidence if the problem is resolved, yet you close out the problem anyway. Burying your head in the sand doesn't make the issue go away. I'm sorry, but you don't close a problem until a resolution is found and the fix confirmed. There is a session bug, which existed in early 4.0 releases, was then fixed, and is now broken again. The last working version of PHP for Windows that did sessions properly was 4.0.3pl1, and nothing thus far indicates that this issue has been resolved since then. I have updated the PHP Version for you to reflect the problem still exists in 4.0.5, the latest release most users would touch. Most PHP users are not about to touch nightly CVS builds. That's why you HAVE point releases like 4.0.3pl1, 4.0.4, 4.0.5, etc. This problem should remain open until it can be confirmed that the bug is fixed. Previous Comments: --- [2001-06-19 09:27:34] [EMAIL PROTECTED] Reopen this if it doesn't work with 4.0.6. --Jani --- [2001-06-15 11:08:43] [EMAIL PROTECTED] 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. --- [2001-06-14 23:18:19] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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. --- 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 -- 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]
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989 User Update by: [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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 -- 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]
[PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced
ID: 8989 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: *Session related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Does this happen with latest snapshot from http://www.zend.com/snapshots/ ?? There have been some fixes regarding this. --Jani Previous Comments: --- [2001-06-07 23:45:32] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8989edit=2 -- 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]
