Reindl Harald wrote:
Am 26.05.2013 17:59, schrieb Thomas Bruederli:
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!
i did not say this, but they are not relevant in all setups
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
and that is why session-files are locked
well, you could came now again with performance but i am developing long enough wep-applications with real load to not see why RC is special
Will PHP just sleep B) until session-files are unlocked or will it just fail in writing the session data? And do database backends of PHPs session handler do locking as well?
Maybe my knowledge about that is outdated and we can indeed drop our custom handlers but that all wasn't given some years ago when we ran into problems with the default PHP session storage. And if PHP offers the ability to implement custom handlers you shouldn't blame the ones who make use of that feature.
And for scalability reasons we should make sure *all* possible PHP session backends behave the same and not only talk about file-based session storage.
Another more performance related reason for you custom handler is the check if session data actually changed before issuing a (useless) update query
without the custom handler there would be no db query at all
I don't get that. AFAIK PHP always writes session data on script shutdown even if it didn't change. Using a database backend thus will trigger useless UPDATE queries. But let's put that aside since that's not the main reason for our custom handler anyways.
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
if it comes to integrity it is a *bad idea* write *lockless* in sessiondata which does not happen in the default handler
@Harald, could you run Roundcube on a PHP5.4 without Suhosin to rule that out first?
it is the combination of Suhosin and PHP 5.4
but since my main-job is php-developer and all applications i developed and maintain except RC are working in the test-setups and on all of the developer-machines i have zero understanding for *one* app which does not and there are much more critical things like a webmail client which is nice-to-have but not more if it comes to business users
Shall I take this as *no*?
Fair enough, but if you're not willing to help us tracking the issue down, then you shouldn't expect a solution anytime soon as nobody else is obviously able to reproduce the errors you're reporting.
** 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
why does this need a *custom* session handler? sorry - no, zero understanding
We had reproducible errors reported where session data was lost due to concurrent requests overwriting each other.
~Thomas