MySQL session handler problems - PHP bug and more

[Mike Baptiste]

I've got Horde 2.0, IMP 3.0, and Turba 1.0 running on Linux with PHP 
4.1.2 and it works well.  However, in anticipation of our load, I was 
trying to get MySQL session handling working.

I settled on a pear based handler (http://pearsession.sf.net) which 
seemed clean and well written.  However, everytime I logout, I get a 
blank page until I click reload.

I've have spent most of today debugging this issue and felt I'd share my 
findings as this is broken and I've still been unable to fix it.

OK - First I found this post 
(http://marc.theaimsgroup.com/?l=imp&m=101429198728711&w=2) from James 
Noyes and the reply from Henry Blackman 
(http://marc.theaimsgroup.com/?l=imp&m=101429244430003&w=2)

James talks about the very same problem I'm having.  James is on to 
something.  The session start in imp/login.php after the session_destroy 
is hanging every time, resulting in the blank page.  Henry mentioned it 
could be a problem with the session handler. I checked the one I'm used 
and it DOES return '' if the sessionid has no data.  I could not find 
any problem with the handler.  I even switched it from deleteing the 
session record to simply setting the data field to '', this did not help.

My error logs show this after the logout:
[Sun Mar 10 15:16:29 2002] [error] PHP Warning:  Constant sid already 
defined in /home/secure/public_html/horde/lib/Prefs.php on line 91
[Sun Mar 10 15:16:29 2002] [error] PHP Fatal error:  Failed to 
initialize session module in 
/home/secure/public_html/horde/lib/Prefs.php on line 91
[Sun Mar 10 15:16:29 2002] [error] PHP Warning:  Failed to write session 
data (user). Please verify that the current setting of session.save_path 
is correct (mysql://phpsess:xxxxxxx@localhost/php_sessions) in Unknown 
on line 0 (pw removed on purpose)

So I poked around the PHP site some to try and gain some insight and 
came across this comment and PHP bug:

leomaciel@kmail.com.br
28-Jan-2002 07:47

Please note that you can NOT session_destroy() and session_register() in
the same request.

If you do this you'll get the error message 'Constant sid already
defined'.

This bug has been reported on June 
2001(http://bugs.php.net/bug.php?id=11643)
and by the time of this posting was not closed yet.

The bug is unresolved, but this is what IMP is doing.  It is destroying 
the session data and then calling session_start

Of course I commented out the session_start and it still hung on the 
next session_register (which does an implied session_start)  No surprise 
there.

I also noticed in big letters on the session-register pages warnings 
about using session_register and the HTTP_SESSION_VARS:

Caution

If you are using $HTTP_SESSION_VARS/$_SESSION, do not use 
session_register(), session_is_registered() and session_unregister().

I'm not very familiar with the horde code, but use PHP a lot and it 
seems that horde/imp is using the session_var array as well as the 
session_register/unregister.

The session_unregister page also mentions this:

Note:  If $_SESSION (or $HTTP_SESSION_VARS for PHP 4.0.6 or less) is 
used, use unset() to unregister a session variable.

Of course the pages don't say WHY this is a problem os I"m not 100% sure 
this is related.  However....

The login.php program seems to do both:

         $HTTP_SESSION_VARS['imp'] = null;
         session_unregister('imp');

         if ($registry->getMethod('auth/logout') == $registry->getApp()) {
             include_once HORDE_BASE . '/lib/Auth.php';
             Auth::clearAuth();
             session_destroy();
             @session_start();

though it sets the variable to null before unregistering (instead of 
unsetting)

So right now I'm totally stuck.  Using file handler - no problem.  It 
seems that this is a PHP bug/problem, but I'm trying to come up with a 
temporary workaround in IMP/Horde until PHP is fixed.

I realize others are using sql handlers and not having this problem.  So 
I'm a big confused as to why they are getting away from it.

Anyone out there have some ideas on what direction I can go next?  Am I 
chasing a red herring with the above bug report and manual comments? 
I've used debug error logs and execution is absolutely hanging in the 
session_start after the session_destroy.  I'm playign around with 
replacing the various session registers and unregisters wiht explicit 
unsets and HTTP_SESSION_VAR sets.  I'll post any more updates if I get 
any farther.

Mike