|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #17512 $_SESSION support may be inconsistent
Submitted: 2002-05-29 14:41 UTC Modified: 2002-10-18 01:00 UTC
Avg. Score:4.9 ± 0.3
Reproduced:12 of 12 (100.0%)
Same Version:9 (75.0%)
Same OS:4 (33.3%)
From: dan at abledesign dot com Assigned:
Status: No Feedback Package: Session related
PHP Version: 4.3.0-dev OS: ANY
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: dan at abledesign dot com
New email:
PHP Version: OS:


 [2002-05-29 14:41 UTC] dan at abledesign dot com
Situation:  Working with PHP4's session functions, I've encountered a problem on a local install (PHP 4.2.1, Apache2 (could also be an Apache2 bug), Windows XP, MySQL 3.23.49) that does not exist with the same script on a Linux/Apache 1.x/PHP 4.1.2 installation with the same PHP configurations.  It would appear to be a bug in PHP's handling of $_SESSION in certain situations, but it's possible something else is going on that has escaped my attention.

Symptoms:  Using $_SESSION as outlined in the PHP docs with session_start() and no session_register() for register_globals being turned off, logging into the script in question creates a session but does not write the actual session data (key/value pairs) to it. Just a session id and expiry.  This happens with either the standard /tmp/ flatfile or MySQL (session_set_save_handler) session logging.

Solution:  The only thing I found that could get it to correctly write the session data is to replace $_SESSION with $HTTP_SESSION_VARS throughout the script. That doesn't make sense, since 4.2.1 is obviously more recent than the 4.1.0 release which added $_SESSION... 

Ok, one step down. More surprising is that on logging out, unset'ing the session variables is not "writing" the empty session to the database. It should leave the session id and expiry in place and wipe out the session data, but all remains untouched. The session variables themselves are being emptied (tested by echoing them to the browser), but that's it. 




Neither of those approaches worked from the standpoint of changing the session (as opposed to the variables' values). The thing that I found which sort of works is to set the session variables to NULL instead of unset'ing them: 

$HTTP_SESSION_VARS['sess_name'] = NULL;

That didn't exactly empty the session, but it did make it invalid, with the following session data resulting: 


as opposed to the valid format which might look like: 


For a username of "admin" and a id of "1". 

I guess that's better than nothing, but it isn't overly assuring that unset() doesn't work...  I did find mention of what appears to be the same problem in another bug tracker report:

Making the above outlined changes did not adversely affect the non-local installation of the script, so it appears to be a good balance if you need something to work on multiple server environments.

A couple of other bug reports that are loosely related by may or may not be the same are:

Dan Kaplan


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-05-30 06:40 UTC]
Can you test the same no W2K ?

Can't reproduce this on W2k, try this simple script and see if it works:


	if (isset($_REQUEST['key']) && isset($_REQUEST['value'])) {
		$GLOBALS[$_REQUEST['key']] = $_REQUEST['value'];
		echo "Registered {$_REQUEST['key']}.<br />\n";

	if (count($_SESSION) > 0) {
		echo "The following session variables are registered:<br />\n";
		foreach ($_SESSION as $key => $value) {
			echo "$key => $value<br />\n";
		echo "<br />\n";
<hr />
<form action="<?=$_SERVER['PHP_SELF']?>" method="post">
	Key: <input name="key"/><br />
	Value: <input name="value"><br />
	<input type="submit" />


Note: you've to refresh after a registration!
 [2002-05-30 12:01 UTC] dan at abledesign dot com
Thanks for the quick reply.

I do have Win2k, but no server setup on that computer, so I can't easily test that piece.

I tried out your sample script and it seems to work fine.

> Note: you've to refresh after a registration!

Do you mean just for that sample script (which did require refreshing) or in general?  With the problem I outlined above, my script normally redirects to a main page after successful login (and subsequent session updating).  To isolate the problem, I had removed the redirect/refresh to see if the session was actually being written on the login page, which it wasn't.  So, I don't think refreshing is the culprit there, since that same approach works fine on non-local installs (including lots of other servers it's been used on).

 [2002-05-30 15:36 UTC] n dot ponsich at netcourrier dot com
Y have the same trouble with win XP and easyPHP 1.6 even if i upgarde PHP to 4.2.1
 [2002-05-30 15:54 UTC] n dot ponsich at netcourrier dot com
sorry for the mistake my post is for the "Bug #17441 session register"
 [2002-05-30 18:06 UTC]
Given your response to my sample tells me that sessions do work properly. I suspect a bug in the code you use or the way  you expect sessions to work.

Try to cut it down to a simple, self-contained example what you're trying to archive.
 [2002-05-30 18:47 UTC] dan at abledesign dot com
> Given your response to my sample tells
> me that sessions do work properly.

The point of the report was not to say that sessions do not work (they obviously do, as shown by the fix I outlined above), rather that certain aspects of them do not appear to be properly supported in some environments.

> I suspect a bug in the code you use or
> the way  you expect sessions to work.

Ok, here is what I've got, in simplified form (no need for you to read through the extraneous hidden fields, MySQL queries, and what not):

-- login form:

print <<<HERE
<form action="$PHP_SELF" method="GET">
<input type="text" name="username" value="" size="20" maxlength="15">
<input type="password" name="password" value="" size="20" maxlength="15">
<input type="submit" value="Submit">

-- login processing script:

(This is actually routed through an index page that starts the session, includes config and library files, page formatting, and includes the requested file, which is the login processing form in this case.)


if (isset($_SESSION["sess_id"])) {
	// remove any existing sessions for this user

$sql = "SELECT * FROM Users WHERE Username='". addslashes($_GET["username"]) ."' AND Password='". addslashes($_GET["password"]) ."'";
$result = mysql_query($sql);
if (!$result || (mysql_num_rows($result) < 1)) {
	// redirect to failed login prompt
} else {
	$row = mysql_fetch_array($result);
	$_SESSION["sess_id"] = $row["ID"];
	$_SESSION["sess_name"] = $_GET["username"];

	// redirect to main page after setting the session
	echo "<script language=\"JavaScript\">window.location='index.php'</script>";

As explained above, that does not work on all servers.  Doing the exact same thing but with $HTTP_SESSION_VARS in place of $_SESSION and not using unset() on the session variables does however work.  Surely I'm not misunderstanding how sessions should work in this example?

 [2002-06-12 05:32 UTC] info at virogo dot com
Same in NT4 / IIS4.

No consistent registering possible...
It writes 2 ses_3237234748 bla bla, one of them is 0 bytes.
The other contains the sessiondata.
But when trying to read out the sessiondata thru $_SESSION, it seems to be empty.
 [2002-08-05 15:12 UTC] zen_kermit at expn dot com
This problem is smattered all over these bug forums. Will someone from PHP please address is it as an actual issue? It has effectivley mangled a few of my websites.
 [2002-08-07 03:06 UTC]
Session work mostly, but the problem original reporter reported do exist. 

We need to fix the way session vars are stored to close this one. (Unless I'm missing the fix ;)

 [2002-09-16 14:12 UTC] mclinden at informed dot net
Just tried the script from mfischer dated 30 May 2002 on the current CVS of 4.3-dev and got some interesting results.

First, keys were stored but not the values.

Second, when the key was a number, any subsequent entry of key-value pairs would overwrite the numeric key although subsequent alphabetic keys would continue to accumulate (still without the values).
 [2002-09-16 14:13 UTC] mclinden at informed dot net
Sorry. Should add that this is Linux 2.4 kernel and Apache 2.0.40.
 [2002-10-02 01:17 UTC]
"Keys are stored, but not the values."

This has been fixed in 4.3 "unstable" CVS -- please give it a try.
 [2002-10-18 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Wed Nov 30 04:05:54 2022 UTC