[RESOLVED] Session data failing to be saved

[cbj4074]

As a bit of background, with the particular PHP application in question, I've always called session_start() in a "global include", the contents of which are executed on every page of a the site. This made sense, because I was accessing session data on every single page.

I later came to realize the caveats of such an approach, namely, unbearable wait-times due to session file locking. So, I decided to restructure the approach to sessions and wrote a couple of simple functions:

class GlobalMethods
{
function sessionStart()
{
	if (session_id() == '') {
		session_start();
	}
}	

function sessionEnd()
{
	if (session_id() != '') {
		session_write_close();
	}
}
}

I removed session_start() from the global include file and combed through the site, placing calls to my custom sessionStart() function just before access to $SESSION data was required, and calls to sessionEnd() once I had what I needed from the $SESSION superglobal.

I've run into several issues. First, the above functions do not behave as I had expected. Any data that I write to the session, e.g. with

$_SESSION['someVar'] = 'someValue';

is not retained across pages. However, if I remove the conditional statements, and do something like the following, the observed behavior is as expected.

function sessionStart()
{
	@session_start();
}	

function sessionEnd()
{
	session_write_close();
}

So, I thought to myself, "Well, I don't really understand why the original functions didn't behave as expected, but this latter approach seems to work without issue. I'll research the 'why' later." I had tested several areas of my site and didn't see any problems relative to sessions.

Then, I came upon the situation that prompted me to post in frustration. I was storing some session data just before sending headers and exiting, and it couldn't be retrieved on the page to which I was redirecting, after calling session_start(). A bunch of other session information was present, but not the most recent information from the previous page in the application-flow. I added the following to the troublesome script, just before the calls to header() and die():

var_dump(session_id());

echo '<br /><br />BEFORE calling sessionEnd:<br /><br />';

var_dump($_SESSION);

GlobalMethods::sessionEnd();

echo '<br /><br />AFTER calling sessionEnd and then sessionStart:<br /><br />';

GlobalMethods::sessionStart();

var_dump($_SESSION);exit;

The above snippet yields the following:

string(26) "sttrjvufik60nmb653ro1ojet7" 

BEFORE calling sessionEnd:

array(1) {
  ["checkout"]=>
  array(4) {
    ["orderId"]=>
    string(5) "19257"
    ["completedSections"]=>
    array(2) {
      [0]=>
      string(13) "accountPrompt"
      [1]=>
      string(13) "paymentMethod"
    }
    ["paymentMethod"]=>
    array(2) {
      ["bindKey"]=>
      string(40) "9f5711356955e4ff844766af6b70b6ee5b5aec7e"
      ["method"]=>
      string(6) "credit"
    }
  }
}

AFTER calling sessionEnd and then sessionStart:

array(1) {
  ["checkout"]=>
  array(2) {
    ["orderId"]=>
    string(5) "19257"
    ["completedSections"]=>
    array(1) {
      [0]=>
      string(13) "accountPrompt"
    }
  }
}

If I examine the actual session storage file, on the filesystem, the data is missing from there, too. The session file is modified each time I reload the page, but the information therein never changes.

Am I missing something terribly obvious? Any help would be sincerely appreciated.

Thanks in advance!

[sneakyimp]

Trying to assign any values at all to $SESSION before session_start() gets called is futile. You should call session_start() before you do anything at all to $SESSION.

[cbj4074]

Thanks for your prompt reply, sneakyimp.

After reading your comment, I double-checked my logic and realized that you are correct; the session was not being started properly.

I came to realize that any time I call session_write_close() and then try to call session_start() subsequently within the script, I run into unexpected problems and behavior.

Perhaps I am misunderstanding the intended behavior of session_write_close(). Is there any reason that session_write_close() should only be called once per script? In other words, is it a bad idea (or outright incorrect) to do something like this?

session_start();
$_SESSION['foo'] = 'bar';
session_write_close();
//Other actions occur...
session_start();
$_SESSION['foo2'] = 'bar2';
session_write_close();
session_start();
var_dump($_SESSION);

Or are session_start() and session_write_close() intended to be used arbitrarily and as often as necessary in any given script?

Thanks again!

[sneakyimp]

I'm not certain, but I don't think you ever need to use session_write_close in practice. I can't really comment on what it does as I don't remember ever calling it. My guess is that you shouldn't be calling it more than once.

[sneakyimp]

session_start() should be used only once per script -- and definitely before you try to do anything at all to the $_SESSION vars.

[dalecosp]

The manual seems to indicate that the reason to use the call is in the event you have multiple PHP pages in iFrames which are all attempting to access the same session "cookie" and have issues due to locking.

So, unless we're dealing with multiple & simultaneous script execution by the same client, there's no need to call it.

[cbj4074]

Thank you for the responses, folks.

dalecosp, the reason for which I am using session_write_close() is as described in the manual: I'm experiencing issues with session locking. Your point that session_write_close() should not be used unless for this purpose is well-taken. It sounds like I should remove all calls to session_write_close() except for on the handful of pages on which session locking is a problem.

Basically, users are able to download considerably-sized files (in excess of 2G😎; these files are sent to the browser via PHP (they are not static downloads from within Apache's document root). I don't want the session to remain locked during what could be a very long download, as this would prevent the user from browsing elsewhere on the site while the download finishes. It would also prevent a single user from downloading two files simultaneously. Furthermore, I intend to show somewhat of a "progress indicator" (in an iFrame) while the download is being prepared, which requires that the session not be locked.

It seems to boil down to the following: is it possible to add new data to the session after calling session_write_close() in a given script? The PHP snippet in my previous post seems to indicate that it is.

The reason I ask is that I'd like to add some information to $_SESSION after the user's download is complete.

Here's what I've been able to determine: the following does not save the data to the session.

function sessionStart()
{
    if (session_id() == '') {
        session_start();
    }
}    

function sessionEnd()
{
    if (session_id() != '') {
        session_write_close();
    }
} 

//Note that this is the custom function, from above, and not a built-in function.

sessionStart();

$userId = $_SESSION['userId'];

//We have all we need from the session (for now); end the session so that requests for other pages may be made via AJAX.

sessionEnd();

//Pass the file to the browser and wait for user to complete download.

//Add some download statistics to the session.

sessionStart();

$_SESSION['timeRequired'] = 'a long time';

//This doesn't seem necessary, and seems to have no effect, either way.
sessionEnd();

If I execute code that mimics the above snippet, the $_SESSION['timeRequired'] value is not saved to the session (that is, I'm not able to retrieve the information on subsequent page requests, nor does the information exist in the actual session data storage file on disk).

However, if I call session_start() in-place of the second instance in which I call my own function in the above snippet, $_SESSION['timeRequired'] is indeed saved. Obviously, the bit of logic that prevents the session from being started after it has already been started (within my custom sessionStart() function) causes the problem. In other words, calling session_write_close() does not cause session_id() to return an empty string. The reasons for which I had made such an irrational assumption in the first place are a mystery! 😕

Additionally, calling session_start() after header() throws a warning (at least with cookie-based sessions), so one would want to avoid such an approach when attempting to modify $_SESSION after sending headers. The error could be suppressed, but is there a better option?

Is the individual at http://us2.php.net/manual/en/function.session-write-close.php#55041 correct when he states the following?

This function is essencial when you change $_SESSION[] variables and then, at some poit in the middle of the script, you send an header("Location: http://...") function to the browser, because in this case the session variables may not be saved before the browser change to the new page.

To prevent from lossing session data, allways use session_write_close before this header function. session_write_close will force session data to be saved before the browser change to the new page.

Hope this will help you not to loose 1 day wondering why people could not authenticate or make other changes in session vars in your site.

I've never found the need to call session_write_close(), explicitly, to avoid session data not being saved when headers must be sent after the $_SESSION superglobal is modified. Perhaps that's because I always call die() after sending headers (in which case session_write_close() is called implicitly).

I've relegated my issues to my own ignorance. Thank you all for pointing me in the right direction here. My code is behaving as I had intended at this point, and I've furthered my knowledge of PHP quite a bit with your help.

[cbj4074]

As a final follow-up, in the end, I modified my functions to allow for the behavior that I desired. "Restarting" a session after writing/closing it with sessionEnd(), as would be necessary in the scenario that out I outlined above, requires an optional argument to be supplied.

//The optional argument should be set to TRUE whenever a call
//to sessionEnd() has been made previously.

function sessionStart($force = FALSE)
{
	if ($force !== TRUE) {
		if (session_id() == '') {
			session_start();
		}
	}
	else {
		@session_start();
	}
}	

function sessionEnd()
{
	if (session_id() != '') {
		session_write_close();
	}
}

This enables me to write the session to disk and close it before I do something that may take an extended period of time, such as passing a 2GB file to the browser, or performing some CPU or disk intensive task on an uploaded file. Once the time-consuming task is complete, I'm able to resume the session and access any previously-stored data.

sessionStart();

$_SESSION['foo'] = 'bar';

sessionEnd();

//
//Do some time-consuming task here; session file should not be locked.
//

//Note that the optional argument is required on all calls to sessionStart() after the first.
//Failure to provide the optional argument will cause new additions to the $_SESSION superglobal not to be saved.

sessionStart(TRUE);

$_SESSION['log'] = 'Everything went swimmingly.';

Per the above example, $_SESSION would contain entries for both 'foo' and 'log'.

[sneakyimp]

This function is essencial when you change $_SESSION[] variables and then, at some poit in the middle of the script, you send an header("Location: http://...") function to the browser, because in this case the session variables may not be saved before the browser change to the new page.

I think this may be true. Imagine this script:

session_start();
$_SESSION['foo'] = 'bar';
header("location: some_other_page.php");

// do something for 20 minutes

$_SESSION['foo'] = '42, the answer to the universe';

My guess is that the foo session var would never be set to the second item because your browser would long since have redirected to the other script and the server would likely have abandoned the long 20 minute process. I'm not entirely sure about this, but the presence of the function [man]ignore_user_abort[/man] makes me think that PHP will abandon a lengthy script if the user disconnects (e.g., in the event the script sent a header).

In my code, a redirect header is always followed immediately by a die or exit command. You shouldn't redirect and then gamble that the code after your redirection might run.

This sort of raises a couple of questions:
1) Why on earth would someone send a redirect header and then fiddle with some session variables after the redirect?
2) Under nominal circumstances, would changes to a session variable be processed after page output is complete?

Question 1 is kind of rhetorical. Question 2 is a legitimate one. I believe PHP is configured to write changes to session storage after a script completes by default so generally speaking you don't need to call the session_write_close command. Sounds to me like you would want to explicitly do this when you might have pages load in rapid succession (like iframes, redirects, etc.). It's not out of the question that your server's file system might be sluggish under heavy load.

As for your script, I wonder why you are checking the value of session_id at all before calling start or close. This is from the docs for [man]session_id[/man]...it's the discussion about the parameter you can use with the function:

If id is specified, it will replace the current session id. session_id() needs to be called before session_start() for that purpose. Depending on the session handler, not all characters are allowed within the session id. For example, the file session handler only allows characters in the range a-z A-Z 0-9 , (comma) and - (minus)!

    Note: When using session cookies, specifying an id for session_id() will always send a new cookie when session_start() is called, regardless if the current session id is identical to the one being set. [/quote]

I know that you are not supplying this value, but I can't help but wonder if PHP might be trying to send cookies when you call the session_id function anyway. I seem to recall that you can't set cookies once you've sent headers or any other output. I might be wrong about that.

At any rate, why bother checking session_id at all? If you want to start a session or close one, just call the start/close functions and don't bother checking whether there is a session id.