|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #15110 Sessions are not saved unless the session contains data
Submitted: 2002-01-18 21:34 UTC Modified: 2003-05-17 13:58 UTC
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:2 (100.0%)
From: fabian at ahrberg dot se Assigned: john (profile)
Status: Closed Package: Documentation problem
PHP Version: 4.1.1 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
40 - 19 = ?
Subscribe to this entry?

 [2002-01-18 21:34 UTC] fabian at ahrberg dot se

session_start() doesn't save the session unless it holds any data. I've just upgraded from 4.0.4pl1. It used to register all session even if they only included a key and no value(data). Maybe it's a feature but it sure messes my stats-scripts... =/

Get back to me with what you need.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-01-18 22:19 UTC]
What do you mean "no value"?
Empty string? NULL? FALSE?

Are you using $HTTP_SESSION_VARS/$_SESSION? or globals?
Is register_globals on?
 [2002-01-19 08:03 UTC] fabian at ahrberg dot se
Register_globals is on.

This is what it used to be:
session_start() registered the session so I could see it even if it's included no data(no registered variables). When I say see, I mean that if i looked in the table I use for writeing the seesions I saw the key, the expiry and no value.

session_start() gives the visitor a key but it doesn't register the key in my sessions teable unless I register a variable to the session.

A bit clearer?
 [2002-02-06 15:32 UTC]
Do any of the PHP developers know if this is intended behavior? It sounds like something that might have been "improved" since sessions were first introduced, so the unnecessary overhead of storing session information with no associated data was removed. It sounds like a good idea to me (the current implementation).

Anyway, this bug is still listed as feedback and needs to either be closed or reopened.
 [2002-02-06 19:58 UTC]
I would say it's a design. As you said, it does not make any sense store session does not have any value.

I make this report to documentation problem, since this behavior is better to be documented.

 [2002-02-07 03:43 UTC] fabian at ahrberg dot se

Well, it still stores the session-keys as files when they?re empty, just not when I want it in a table. I use this to differ my sites sessions from other sites on the server and I when I had all sessions(empty or not) in a table I used it for "right" now stats. Now I get empty session as files with the session key as name and the sessions with data in my table. This makes it impossible for me to count how many sessions belong to my site because I'm not the only one using the server. So WHY are empty sessions stored as files and full sessions as files when I store them as files BUT when I store the sessions in a table I get the empty ones in files, along with the other sites', and the sessions with variables which belong to my site, turn up in the table as they're supposed to. I WANT all the sessions in ONE place... =( *going back to 4.0...*
 [2002-02-07 04:00 UTC]
This is due to implementation difference by nature. "files" save handler creates session file when _open_ is called. In contrust, database storage with "user" save handler, there is not need to create session record when open or read is called. If session is started by there is no data to save, _write_ is not called for both user and files handler, but there will be empty sesson data file since it's already created.

I think this behavior is reasonable. If user don't like certain save handler behavior, user should use other or implement one by themself.

For example, "session_pgsql" save handler does not even use "gc_probability" for performance reason. It performs GC with specified time interval. It also does not return session data when data is expired.

I mean all save handlers does not work exactly the same way ;)
 [2002-02-07 05:40 UTC] fabian at ahrberg dot se
Ah well, since I'm the only one complaining I guess no one will do anything about it. For me it's back to 4.0 because I really used the previous way it worked. =/

 [2002-02-08 02:19 UTC]
What is the big problem here exactly? I fail to understand why this is important for you.

 [2002-02-08 05:48 UTC] fabian at ahrberg dot se
I share a server with a couple of other sites using php and I'm the only one using mysql to store sessions. By storing all my sessions in a table, both empty and not, I get a measure of how many sessions my site has started. This gives me a rough idea of how many vistors I have at a specfic time, just by counting the rows in the table. Further on, I differ logged in users by counting those who have the a flag registered. This gives me fast and rough stats of how many users that are visisting the site and how many of them who are logged in.
Now, when I get the empty sessions all mixed up with the other sites ut gets way too rough. I have thought of a couple of possible solutions with by always registering a variable to session but it makes it more ineffcient than before.

I think you get the picture. Maybe you have a simple soloution, if so please share =). I've gotta go now. Have a nice weekend.
 [2002-02-08 07:06 UTC]
If you have your own save handler functions, you can do what ever you want with you functiions. 

For example, if session is new (no record in your DB when read is called), just insert it when close is called.

 [2002-08-23 08:03 UTC]
Update summary
 [2002-11-28 18:11 UTC]
I'm going to update the docs to reflect this behavior.

 [2003-05-17 13:58 UTC]
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at
In case this was a documentation problem, the fix will show up soon at

In case this was a website problem, the change will show
up on the site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.

 [2020-02-07 06:12 UTC]
Automatic comment on behalf of jan
Log: - fix #15110
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Fri Dec 08 17:01:28 2023 UTC