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?
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