On Sunday, May 26, 2013 at 5:59 PM, Thomas Bruederli wrote:
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.
I'm not a 100% sure I understand the example. Can point out where this issue bubbles up in RoundCube?
I just haven't heard of this issue either. But I'd like to understand.
It doesn't sound like databasing the sessions would be a solution either if one process wipes out another process' data.
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.
As far as I understand, what happens in a request, stays in a request. I don't see how one request would override another.
The backend shouldn't matter. Databased sessions can have some advantages as they make scaling infrastructure easier but of course they could be considered overhead in a single-server setup.
I think the backend (file storage, database, memcache, redis) etc. should not have an impact unless we delete all data and re-save it every time. But anyway, let me know if you can explain this in more details.
Maybe this is an artifact from PHP4 times?
On Wed, May 22, 2013 at 9:00 PM, till <klimpong@gmail.com (mailto: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?
They do — but RoundCube's session handling does something else which makes it incompatible with Suhosin. I've been running various Symfony2 (actually Silex) and ZF1 projects with their session handling code and Suhosin enabled — no issues.
But I also agree that this is not a new issue. It's why we suggested people turn off certain Suhosin options (see installer checks).
Till