That's anyway a different issue likely coming from a GET request subsequent to a REPORT or PROPFIND request. That should go into a separate ticket, preferably with a sample calendar entry that causes sync failures.

This is a known problem fixed loooong time ago: https://issues.kolab.org/show_bug.cgi?id=3049

In T474#6337, @greve wrote:

Torsten: Look for events that have a UID of https://some.some.some/some/some -- these apparently make SabreDAV choke and die badly.

How about multi channel video communication? I think a Jitsi Videobridge component is work a look, it is a XMPP plugin so it can work hand and hand with the solution for Kolab XMPP. Also offers a SIP Gateway and a WebRTC client.

Torsten: Look for events that have a UID of https://some.some.some/some/some -- these apparently make SabreDAV choke and die badly.

Torsten reports this also happens to him with his personal server, no HA Proxy involved: https://github.com/bitfireAT/davdroid/issues/542#issuecomment-113499114

Ah, interesting. Indeed I tried kolabsystems.com. So I think we narrowed this down enough that it should be thrown over to Ops for looking at HAProxy, and perhaps documenting what has been going on there also for future deployments.

It works for me with caldav.kolabsys.com but I also see the same (HTML) 404 response from caldav.kolabsystems.com. Thus I assume the latter is also behind a haproxy configuration and the former lets me access the iRony access directly.

Interesting, thanks a lot for that.

Confirmed with apps.kolabnow.com but not with a direct connection to a Kolab server. The 404 error seems to be a response from the haproxy and the REPORT request never makes it to the iRony backend service. Looking at the payload of the response, you'll see a HTML error page from Kolab Now and not a valid DAV response. Thus, haproxy needs to be configured to forward REPORTrequest types to the iRony backends.

There's also managesieve_conn_options which need to be set or the code should be changed to fallback to imap_conn_options if not set?

The functions get_uid() and set_uid() functions [[https://git.kolab.org/diffusion/RPK/browse/master/plugins/libkolab/lib/kolab_storage_folder.php;a52bf1abe3d7f54fc6424237c282e0d40c507506$147|[1]]] are likely causes of the aforementioned discrepancy of folder metadata values in different namespaces.

Update https://github.com/bitfireAT/davdroid/issues/542#issuecomment-112361204 copied here for convenience:

would we require including the ability to invite people to edit documents they do not have the appropriate (IMAP-level) write access to?

would we require including the ability to invite people to edit documents they do not have the appropriate (IMAP-level) write access to?

Cachet HQ is a Free Software dashboard software that we might want to consider to use for this. There is a public demo as well.

section 3.6 of RFC 3253 is the relevant RFC section. Wondering whether "(DAV:supported-report)" is what should be issued if REPORT is supported. Also raised that question with the client:

In T221#5523, @vanmeeuwen wrote:

In T221#2797, @bruederli wrote:

Basically all options one can pass to the HTTP_Request2 constructor should be configurable, including

You mean, they should already be configurable (current codebase?).

In T221#2797, @bruederli wrote:

Basically all options one can pass to the HTTP_Request2 constructor should be configurable, including

save_tags() (or more generically, write operations) should probably invalidate the cache(s) related to it, and as a matter of efficiency, one might seed the cache again with the internal structs rather than obtain them all all over again from source.

This has been established to be of critical importance.

PHP 5.4 is available for CentOS7, overall testing and QA still pending.

All subtasks are closed? Can we close this one as done or do we need a new subtask for a more recent PHP version?

I just updated the diff to support working as the main backend, and fixed some problems with HTTP authorization.