php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #8989 Bug#5493 resurfaced
Submitted: 2001-01-29 18:06 UTC Modified: 2001-12-05 00:11 UTC
From: fseesink at usa dot net Assigned:
Status: Closed Package: Session related
PHP Version: 4.0.6 OS: Windows NT 4 SP5(IIS4)/2000 SP2
Private report: No CVE-ID: None
 [2001-01-29 18:06 UTC] fseesink at usa dot net
v4.0.4pl1 CGI version, with or without v1 of Zend Optimizer,
is once again demonstrating similar session file generation
as I reported earlier in BUG #5493.  It looks like an old
bug has snuck back in the code.

I believe BUG #8912 also relates to same issue.  Note I have
not yet tested the ISAPI module.

Using the same script as in BUG #5493, I am now seeing
similar, though not the same activity.  Firing up a new
browser, here is what I am seeing as I load the pages
Page1.PHP thru Page4.PHP IN ORDER:

 1. Page1 creates sessionid file
 2. Page2 updates initial file fine
 3. Page3 -"-
 4. Page4 creates new sessionid file (size 0 bytes, as will
be all sessionid files from this point on).  From this point
on, we will never get valid session data again, just as
before with this bug.
 5. Page1 creates new sessionid file
 6. Page2-3 no new file
 7. Page4-1 create new files
 8. Page2-3 no new file
 9. Page 4-1 create new files
10. Page2 no new file
11. Page3-4 create new files *PATTERN CHANGE
12. Page1-2 no new file
13. Page3-4 create new files
14. ***Steps #12-13 repeat 5x ***
15. Page1 creates new file
16. Page2-3 no new file
17. Page4 new file

The pattern seems to fluctuate back and forth between
Page4-1 creating new sessionid files and then Page3-4
creating sessionid files.

I suspect whatever was at the root of BUG #5493 will likely
be the cause here as well.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-05-22 21:11 UTC] sbergmann@php.net
Does this problem persist with a recent version of PHP 4 (like latest CVS or PHP 4.0.5)?

 [2001-06-07 23:41 UTC] fseesink at usa dot net
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-06-07 23:45 UTC] fseesink at usa dot net
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-14 23:18 UTC] sniper@php.net
Does this happen with latest snapshot from 
http://www.zend.com/snapshots/ ??

There have been some fixes regarding this.

--Jani

 [2001-06-15 11:08 UTC] fseesink at usa dot net
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-19 09:27 UTC] sniper@php.net
Reopen this if it doesn't work with 4.0.6.

--Jani

 [2001-06-19 10:56 UTC] fseesink at usa dot net
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 16:45 UTC] derick@php.net
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 17:55 UTC] fseesink at usa dot net
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-25 13:57 UTC] fseesink at usa dot net
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-26 06:24 UTC] sniper@php.net
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++;

?>

 [2001-06-26 12:36 UTC] fseesink at usa dot net
That's very nice.  But that is not what this bug report was about.

PHP v4.x has always been able to initially create a session variable.  The challenge is NOT within a single page.  The problem, as clearly described in earlier postings of both this problem and an earlier problem (see #5493 for source used), is the maintenance of session variables BETWEEN pages...the whole POINT of using session variables (i.e., maintaining state, vs. the stateless nature of HTTP).  And note, before giving another trite example, that I provided source for you to use.  But just in case you did not read this actual problem in its entirety, here's the breakdown once more:

1.  Create the file page1.php as follows:
__________________________________________________
<?
session_start();
if (!$PHPSESSID) {
	$userid=100;
	$firstaccess=time();
	$lastaccess=time();
	session_register("userid");
	session_register("firstaccess");
	session_register("lastaccess");
}
$lastaccess = time();
?>
<HTML>
<HEAD>
<TITLE>Page 1</TITLE>
</HEAD>
<BODY>
This is page 1.<br>
<?
   echo "\$PHPSESSID   = '$PHPSESSID'<br>";
   echo "\$userid      = '$userid'<br>";
   echo "\$firstaccess = '$firstaccess'<br>";
   echo "\$lastaccess  = '$lastaccess'<p>";
?>
<A HREF="page2.php">Page 2</A>.<p>
</BODY>
</HTML>
__________________________________________________

2.  Create files page2.php, page3.php, & page4.php, copying the code above.  The only changes that needs to be made are to change the <TITLE> for each file as appropriate, the one line (though this was superflous), and the <A HREF> tag so that essentially

PAGE1.PHP -> PAGE2.PHP -> PAGE3.PHP -> PAGE4.PHP -> PAGE1.PHP

thus creating a loop that cycles around the 4 pages.

3.  Make sure the PHP.INI file is properly configured to store session files (for this example, \InetPub\sessions).  Then either open a Command Prompt to this directory or use Explorer (whatever suits you).

4.  Serving these files from IIS (say \InetPub\wwwroot), load page1.php.
5.  Look in the session directory.  You should see a session file created.  Note its size (60 bytes in this case).
6.  Now start clicking on the link on page1.php.  This will load page2.php, which shows the current value of the session ID.  Keep clicking on the links and keep watching the session directory.

What you will find is that new session files are being created, session files that are 0 bytes and contain NOTHING.  This is a serious problem.  It's makes session management useless in PHP under Windows.

Hopefully it's isolated to just the Winblows world using IIS.  Unfortunately, that's the environment I work in, and since PHP is offered, I provide feedback and bug reports whenever I run into such problems.

Maybe I come across as a bit brusk, but truth be told, the manner in which you write, sniper, demonstrates at best a lack of tact and awareness of the impact your choice of words has, and at worst it demonstrates a serious lack of social skills and a beligerent nature not conducive to software development.  Each time you write you indicate that you haven't bothered to READ the bug report and really know what the problem is.  I think I've done a reasonable job of detailing EXACTLY how to duplicate what I have done.  I did not just write "Sessions suck.  Fix it."  If you had read it, you might not have written that last response.

I realize this is an open source project, and PHP, like Apache and all other such projects rely on the hard work of many committed people who sacrifice time, energy, and effort to make it the best damn server side scripting language I've seen.  It's clean, it runs well, and (except for this bug which was squashed, then resurfaced and has persisted through 4 revisions now) is pretty rock solid.  And so don't misunderstand.  I do sincerely appreciate all the time/energy/effort/etc. you and everyone on the PHP team put forth.

However, the tonality of your words in repeated messages has come across as beligerent, compative, hostile, and appears based on a lack of understanding of the bug report.  Maybe that is not truly the case.  Maybe you're just a damn fine programmer but suck at writing skills.  We all have our strong & weak points.  But the words you have chosen, and the comments you have put forth (like the last message which really shows you misunderstand the bug being reported) don't exactly endear you.  And this appearance of being hostile is NOT something anyone, including myself, should have to tolerate when all I am trying to do is help you to pinpoint a bug so you can fix it.

So, with that said, let's see if we can't put this bug to bed once and for all.  That's what this is all about, isn't it?  Working together against a common foe:  the software bug.
 [2001-06-27 11:26 UTC] sniper@php.net
1. Only person using hostile tone around here is you. 
2. This is a BUG database, not a discussion forum.
3. Did you or did you not try my short example script??
Does the number get higher or does it always give you
an error message when you reload the page?
4. Is the session cookie set at all? Does this happen with any browser? 
5. What is the value for register_globals in your php.ini?

--Jani

 [2001-07-02 00:39 UTC] fseesink at usa dot net
>1. Only person using hostile tone around here is you.

   Do you even READ what you write and consider how it sounds?  I disagree with your opinion, but no point discussing it with you.  Let's just stick to bug hunting.

>2. This is a BUG database, not a discussion forum.

   Good point.  That's why I posted here what I wrote for both this problem and its earlier incarnation, #5493.  And if you bothered to read the postings, you would've found all the answers to your questions.

I didn't post a bug with the idea to have the bug dismissed without validation, as #5493 was (by you as well, sniper).  And to point out something, I only became aware of this last post of yours when I visited the website.  I was NOT sent an e-mail of this last post.  This is exactly how #5493 died.  I only learned of it later.  Luckily I decided to check the site, or this problem may have died as the last...without proper resolution.

>3. Did you or did you not try my short example script??
>    Does the number get higher or does it always give you an
>    error message when you reload the page?

Oops, that one IS my goof.  I looked at my last post and saw that I didn't spell it out very well.

Yes, I ran your example script.
Yes, the number gets higher.
But again, this is NOT what the bug report was about.

>4. Is the session cookie set at all? Does this happen with any
>    browser?

Yes, the session cookie is set initially.  In your example script, it works fine.  In my example scripts, new session files are generated over time as you cycle thru the links.  See bug #5493 for more details.

The only browsers I have handy are IE 5.5SP1 & Netscape 4.77 running on Windows 2000.  I'll double-check in the morning, but I believe it occurs regardless of browser.  Will see if I can get confirmation from other browsers such as Konqueror.  May take a day or two.

>5. What is the value for register_globals in your php.ini?

register_globals = ON


FINAL NOTES:

1. On http://www.php.net/bugs.php  displayed all OPEN bugs of type SESSION RELATED.  Problem #8989 was not listed.  Should this be reported as a separate problem with the site, and if so, what is the appropriate category? (Display done multiple times with same result.)

2. Last posting
   "[2001-06-27 11:26:13] sniper@php.net"

was NOT e-mailed to me by the system.  Again, should this be reported as a separate problem with the site, and if so, what is the appropriate category?  I would like to make sure I receive your postings so that I can be sure to reply in a timely manner.

 [2001-07-02 14:30 UTC] fseesink at usa dot net
Configured Windows 2000/IIS 5 webserver with PHP v4.0.6 CGI (disabled Zend Optimizer, etc.).  Tried accessing the page1.php-page4.php test I provided earlier.  Used Netscape v4.77 & IE 5.5SP1 for Windows 2000, as well as Konqueror 2.1.1 & Netscsape 4.76 under KDE on Red Hat Linux 7.1.  All browsers have cookies enabled.

In all cases, initial session file is created with variable values stored properly.  But as you move through the pages, new session files are generated (effectively different session IDs), with all session files after the 1st being 0 bytes.  In short, session not maintained.

Again, this issue existed prior to PHP v4.0.2.  The Windows version of PHP CGI v4.0.2 - v4.0.3pl1 (the latter being what I still use today) all performed properly.  With v4.0.4, problem resurfaced and has remained.

I don't know if there is a way to see what changes were made from 4.0.1pl1 -> 4.0.2 and then 4.0.3pl1 -> 4.0.4 and if any changes were accidentally undone.

 [2001-07-02 15:01 UTC] fseesink at usa dot net
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 under Windows is the v4.0.3pl1 CGI edition.  If you can find others to validate that newer versions work properly using the script I provided, I'm open to suggestions.  I had this issue under Windows NT4/IIS4, now still with Win2K/IIS5.  I do not believe it to be an isolated case.

If anyone else is reading this bug report experiencing similar problems, please post so the developers will know.
 [2001-08-23 12:30 UTC] fseesink at usa dot net
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-11-18 01:21 UTC] sebastian@php.net
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-11-18 13:34 UTC] fseesink at usa dot net
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.
 [2001-11-19 12:56 UTC] fseesink at usa dot net
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-24 19:19 UTC] sniper@php.net
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-24 22:55 UTC] fseesink at usa dot net
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 22:57 UTC] fseesink at usa dot net
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-26 20:06 UTC] fseesink at usa dot net
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-12-02 01:34 UTC] fseesink at usa dot net
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.

 [2001-12-04 19:32 UTC] sniper@php.net
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-05 00:11 UTC] fseesink at usa dot net
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 Bastiaan.Bakker@lifeline.nl 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.

 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Wed Feb 20 16:01:26 2019 UTC