Many open sessions left on Horde



  • Each synchronization of calendars/contacts between DAVdroid 0.7.7 and Horde 5.2.6 creates several new user sessions, without ever closing them. After a day, I see hundreds of open sessions in Horde from a single DAVdroid client. Turning the preemptive authentication on/off had no effect.
    This problem did not occur when using a different CalDAV client, e.g. Thunderbird Lightning.
    Does anyone have a hint? Thx.


  • developer

    What do you mean by "open session"? DAVdroid doesn't use stateful operations such as locks, so every request is stateless and doesn't "create a session". I also don't know what "closing a session" could mean in this context.

    Do you have more detailed information about this?



  • This is a screenshot taken from Horde after I invoked synchronization from a single device:
    sessions
    It appears to create a new session every 4s. It creates several sessions for every calendar it synchronizes. My calendar and contact list both contain hundreds of items.
    When I do the same from other DAV clients like Mozilla Lightning, I only see 1 session per calendar per client, even after multiple synchronizations.
    Sessions are probably PHP sessions and are identified by cookies. You are therefore right, they cannot be closed from the client, but they could be reused instead of creating new ones. Does DAVdroid support cookies? I know that the CalDAV protocol should be stateless, but many implementations just add some statefullness by using cookies.


  • developer

    DAVdroid doesn't use cookies, which is a good explanation of why Horde logs a new session for every request. Do you know whether cookie support is mandatory for CalDAV clients so that we can see on which side the problem is?



  • I don't think it is mandatory. But I know for sure that on the server side, both Horde and Google Calendar use cookies in CalDAV. And on the client side, at least Mozilla Lightning supports cookies, even though it sends credentials in every request (=preemptive authentication?). So cookies in CalDAV are definitely not just a Horde-specific thing.



  • From a quick search it seems that the CalDAV RFC doesn't mention cookies at all, which implies they're optional. I don't see any harm in supporting them though, it sure wouldn't be an RFC violation.

    From a quick grep this line seems responsible for that.



  • It would be great if this got implemented.


  • developer

    From a quick grep this line seems responsible for that.

    I don't know where HttpClient creates it cookie store and whether there are things to take into consideration (multi-threading support etc.).

    Could you please find out whether cookie support is mandatory for CalDAV clients? If not, a Horde issue would have to be created, too – regardless of whether the support is implemented in DAVdroid or not.



  • I think that if a server wants to track the list of currently connected CalDAV clients, then its only option is to use cookies.
    And it really is not just a Horde thing: Google CalDAV API Developer's Guide states in a footnote:
    For account security and to prevent abuse, Google might set cookies on client applications that access data via CalDAV.



  • Could you please find out whether cookie support is mandatory for CalDAV clients?

    There is no explicit mention of cookies or RFC 6265 (the "cookie RFC") in the CalDAV RFC. I think Horde is entirely compliant: It doesn't really rely on cookies being supported by the client, but provides a nice feature if the client does.


  • developer

    It seems the HttpComponents used by DAVdroid don't provide a persistent cookie store. The BasicCookieStore (which will be used when the .disableCookieManagement is removed) is only an in-memory list of cookies. This would suffice to make a sync process one "session" and still won't have the complexity of a persistent cookie store, so I'll enable it.


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.