I'm unable to reproduce the initial issue in Kolab:Development. The TRIGGER property is not broken when importing ics using iRony and then exporting it there.

I found it's libkolabxml issue, see T670. However, some code alignments and workarounds still needed in libkolab and libcalenaring plugins.

1. kolab-syncroton does not support Reminder=0 now, need to be fixed.
2. There are issues in Roundcube UI. While you can set alarm to "0" when you visit the event again there are small glitches in the alarm description and edit field. The reminder message is not displayed.

BTW, when adding such event via Roundcube the TRIGGER is correctly saved as -PT0M. So, it looks that iRony/SabreDAV is doing something wrong here.

In T474#6995, @bruederli wrote:

In T474#6994, @vanmeeuwen wrote:

The entire HAProxy side of the topic is busted, it had nothing to do with anything. The REPORT requests are getting through to iRony.

Really? And why am I seeing the HTML content of the Kolab Now website in the 404 responses I get in those REPORT requests?

FWIW, my private account (on apps.kolabnow.com) is still failing in the same way right now. Let me know if/how to provide debugging info.

In T474#6995, @bruederli wrote:

Really? And why am I seeing the HTML content of the Kolab Now website in the 404 responses I get in those REPORT requests?

In T474#6994, @vanmeeuwen wrote:

The entire HAProxy side of the topic is busted, it had nothing to do with anything. The REPORT requests are getting through to iRony.

In T474#6993, @bruederli wrote:

I'm unable to reproduce any false behavior. See https://issues.kolab.org/show_bug.cgi?id=3049#c9

I'm unable to reproduce any false behavior. See https://issues.kolab.org/show_bug.cgi?id=3049#c9

A sample calendar entry has been added to https://issues.kolab.org/show_bug.cgi?id=3049

Hi @vanmeeuwen, since you debugged this, do you have a "sample calendar entry that causes sync failures" that you can attach to this ticket?

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.

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.

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

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:

This comment raises the question of whether 404 is a valid response to a valid URL in case there are no entries to report. This may warrant checking against the specification and other implementations.

All dependencies resolved.

Further commits related to this issue: rI81356faa, rI01135d9d, rI73396ba5, rRPK6c0d0f8d, rRPKa6daa4d1, rRPK6effb4c9

Moved full scheduling inbox support to T93 for later implementation.

Completed in rI8f79e138a62d

Done in iRony.git

Already partially implemented in the dev/sabredav2 branch. Needs review, testing and finalization after merge