Hello!
I'm trying to ignore all the rants and personal accusations and get back to the a constructive conversation about a technical problem. First, let's start a new thread since it has actually nothing to do with the 0.9.1 update.
Second, there are reasons that Roundcube comes with a custom session handler and those are still valid. We didn't do this just for fun, believe me!
The main reason are concurrent http request which alter session data. Image the following scenario:
A) [r]----------- big file being uploaded ------------[w] B) [r]----- fast upload ----[w]
In PHP, session data is read when the process starts and written when the process ends. With the scenario from above, the session changes of request B) would be lost when A) finishes. Until now I don't know of any solution with default PHP session handlers that would be able to handle such a case properly. Another more performance related reason for you custom handler is the check if session data actually changed before issuing a (useless) update query.
Sure, we could store file upload information somewhere else than in session but the underlying problem of concurrent requests overlapping each others still persists and can happen in other cases, too.
On Wed, May 22, 2013 at 9:00 PM, till klimpong@gmail.com wrote:
I agree that session handling could be nicer in RoundCube — or maybe not at all. ;-) If we wouldn't have customized session handling code we could let people configure PHP directly to use the filesystem, memcache or database. I think the least we could (or should) do is use an external library for session handling because that doesn't seem our domain (which is an email client).
Not sure if we could use something from Symfony2 or ZF2. They each provide wrappers — PHP 5.3, et all. Are people ready to move/upgrade yet?
We're open for suggestions to get rid of the custom session handlers but please keep the above scenario in mind. Switching to an external library might be a solution but don't they use custom save handlers, too?
Speaking of which: what Roundcube does is to call session_set_save_handler() in a very early stage of the script startup. That's the API PHP provides and we sticked to the documentation for implementing the handler functions including returning true to signalize success. Unfortunately I don't have an explanation for the errors you reported without being able to reproduce it. So let's try it the old fashioned way and eliminate possible factors. @Harald, could you run Roundcube on a PHP5.4 without Suhosin to rule that out first?
And please everybody, choose your words wisely!
Regards, Thomas
-------- Original-Nachricht -------- Betreff: Re: [RCD] Update 0.9.1 released Datum: Mon, 20 May 2013 16:39:51 +0200 Von: Reindl Harald h.reindl@thelounge.net
and when will sessions continue to work on machines with Apache 2.4 / PHP 5.4 / MariaDB while the error messages below make ZERO sense because RC refuses to work with a untouched session management like every other webapp
would RC use simply session_start() and not fuckup the admin settings it *would* in fact use /var/www/sessiondata and it would it use *with success*
** give us a option to NOT touch any session setting **
P.S. we can but for the just explained reasons your Roundcube users will complain about lost attachments and other weird behavior.