I can't make a formal announcement of beta9 until tomorrow when I get my coworker to upload the distro to cyrusimap.org, but here it is if you want to give it a try:
http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.4.17-caldav-beta9.tar.gz <http://www.contrib.andrew.cmu.edu/%7Emurch/cyrus-imapd-2.4.17-caldav-beta9.tar.gz> On 12/16/2013 04:19 PM, Marty Lee wrote: > Thanks for all the hard work to get the actual answer Ken; I’ll apply the > patch to my > local server for me to test (only 2 of us using the calendar stuff at the > moment) and > wait with baited breath for an apple update :-) > > If you get wind of apple fixing things, let me know - if I spot it at this > end, I’ll send > something out too. > > Cheers > > marty > > > > On 16 Dec 2013, at 19:09, Ken Murchison <mu...@andrew.cmu.edu> wrote: > >> I confirmed that the DELETE problem is indeed a bug in the Apple client, and >> that Apple is aware of it. I'm somewhat reluctant to to include a fix in >> Cyrus for a bug in a client that will hopefully get fixed sooner rather than >> later. The patch below will work around the problem by making the faulty >> conditional DELETE a non-conditional one. But, by doing so we may delete a >> resource that has been changed by another user/client/session. Given that >> we really don't support shared calendars at the moment, this probably isn't >> a big deal but I don't really want to create potentially bigger problems >> moving forward. >> >> The real fix is Apple correcting their client to use an If-Match header >> rather than If-Schedule-Tag-Match header if the resource doesn't have a >> Schedule-Tag and/or isn't a scheduling object. >> >> >> On 12/14/2013 01:02 PM, Ken Murchison wrote: >>> I just committed a fix to git for the 406 response to GET. I will make >>> a beta9 release with this fix, and hopefully with a fix for the DELETE >>> issue by early next week. >>> >>> I have an email into one of the CalDAV experts that I know at Apple to >>> see what CalendarServer does with the empty If-Schedule-Tag-Match >>> header. I think its a bug in the Apple client, but I will have to come >>> up with a sane workaround for it. In the meantime, this uncommitted >>> patch should fix your problem with DELETE: >>> >>> >>> diff --git a/imap/http_caldav.c b/imap/http_caldav.c >>> index c00223f..641feb8 100644 >>> --- a/imap/http_caldav.c >>> +++ b/imap/http_caldav.c >>> @@ -695,6 +695,7 @@ static int caldav_check_precond(struct transaction_t >>> *txn, const void *data, >>> >>> /* Per RFC 6638, check Schedule-Tag */ >>> if ((hdr = spool_getheader(txn->req_hdrs, "If-Schedule-Tag-Match"))) >>> { >>> + if (!*hdr[0]) return precond; /* XXX Hack for bug in Apple client */ >>> if (etagcmp(hdr[0], stag)) return HTTP_PRECOND_FAILED; >>> } >>> >>> >>> >>> >>> On 12/14/2013 09:39 AM, Marty Lee wrote: >>>> No worries.. I'm about to get back onto another train so will back out >>>> b8.. Only me using it in earnest, so if you need anything else tested >>>> before pushing out, just send me a link. >>>> >>>> Marty Lee >>>> v: 07827 950 918 >>>> >>>>> On 14 Dec 2013, at 14:26, Ken Murchison <mu...@andrew.cmu.edu> wrote: >>>>> >>>>> Hi Marty, >>>>> >>>>> Thanks for the info. The 406 is in response to the GET, caused by a bug >>>>> I introduced when I added support for jCal and xCal data. I can't >>>>> believe that this didn't present itself in my testing. I will need to >>>>> fix this immediately. You probably want to downgrade to beta7 in the >>>>> meantime. >>>>> >>>>> I *think* the problem with DELETE is that iCal is sending an empty >>>>> If-Schedule-Tag-Match header. I will need to test this here and possibly >>>>> talk to the Apple guys to find out why they are sending an empty header, >>>>> and what they expect the behavior to be. >>>>> >>>>> >>>>>> On 12/14/2013 03:09 AM, Marty Lee wrote: >>>>>> Ken, >>>>>> >>>>>> I haven’t but have just taken the opportunity to update to Beta 8 and >>>>>> also to refresh Sqlite, which >>>>>> seems to be the source of the error message… >>>>>> >>>>>> Using cyrus beta 7, the iCal client would delete the event, but when it >>>>>> updated with the server, the >>>>>> event would magically just re-appear. With b8, this has changed; now I >>>>>> get a dialog box: >>>>>> >>>>>> ------ >>>>>> The request for “Marty” in account “Maui” failed. >>>>>> >>>>>> The server responded with >>>>>> “406” to operation CalDAVDeleteEntityQueueableOperation. >>>>>> ----- >>>>>> >>>>>> Telemetry log: >>>>>> >>>>>> <1387007669<DELETE >>>>>> /dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics >>>>>> HTTP/1.1 >>>>>> Accept-encoding: gzip, deflate >>>>>> Max-forwards: 10 >>>>>> Accept-language: en-gb >>>>>> User-agent: Mac_OS_X/10.9 (13A603) CalendarAgent/174 >>>>>> Host: 192.168.253.16:1443 >>>>>> Accept: */* >>>>>> Content-length: 0 >>>>>> X-forwarded-server: dav.maui.co.uk >>>>>> If-schedule-tag-match: >>>>>> X-forwarded-for: 176.12.107.140 >>>>>> Authorization: Basic ... >>>>>> X-forwarded-host: cal.maui.co.uk >>>>>> >>>>>> BEGIN:VCALENDAR >>>>>> VERSION:2.0 >>>>>> PRODID:-//Apple Inc.//Mac OS X 10.9//EN >>>>>> CALSCALE:GREGORIAN >>>>>> BEGIN:VTIMEZONE >>>>>> TZID:Europe/London >>>>>> BEGIN:DAYLIGHT >>>>>> TZOFFSETFROM:+0000 >>>>>> RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU >>>>>> DTSTART:19810329T010000 >>>>>> TZNAME:BST >>>>>> TZOFFSETTO:+0100 >>>>>> END:DAYLIGHT >>>>>> BEGIN:STANDARD >>>>>> TZOFFSETFROM:+0100 >>>>>> RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU >>>>>> DTSTART:19961027T020000 >>>>>> TZNAME:GMT >>>>>> TZOFFSETTO:+0000 >>>>>> END:STANDARD >>>>>> END:VTIMEZONE >>>>>> BEGIN:VEVENT >>>>>> CREATED:<1387007670<GET >>>>>> /dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics >>>>>> HTTP/1.1 >>>>>> Accept-encoding: gzip, deflate >>>>>> Max-forwards: 10 >>>>>> Accept-language: en-gb >>>>>> User-agent: Mac_OS_X/10.9 (13A603) CalendarAgent/174 >>>>>> Host: 192.168.253.16:1443 >>>>>> Accept: */* >>>>>> Content-length: 0 >>>>>> X-forwarded-server: dav.maui.co.uk >>>>>> X-forwarded-for: 176.12.107.140 >>>>>> Authorization: Basic ... >>>>>> X-forwarded-host: cal.maui.co.uk >>>>>> >>>>>> BEGIN:VCALENDAR >>>>>> VERSION:2.0 >>>>>> PRODID:-//Apple Inc.//Mac OS X 10.9//EN >>>>>> CALSCALE:GREGORIAN >>>>>> BEGIN:VTIMEZONE >>>>>> TZID:Europe/London >>>>>> BEGIN:DAYLIGHT >>>>>> TZOFFSETFROM:+0000 >>>>>> RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU >>>>>> DTSTART:19810329T010000 >>>>>> TZNAME:BST >>>>>> TZOFFSETTO:+0100 >>>>>> END:DAYLIGHT >>>>>> BEGIN:STANDARD >>>>>> TZOFFSETFROM:+0100 >>>>>> RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU >>>>>> DTSTART:19961027T020000 >>>>>> TZNAME:GMT >>>>>> TZOFFSETTO:+0000 >>>>>> END:STANDARD >>>>>> END:VTIMEZONE >>>>>> BEGIN:VEVENT >>>>>> CREATED:20131214T075350Z >>>>>> UID:0C48ECD9-44A7-4F1F-9C87-9A2EF647C574 >>>>>> DTEND;TZID=Europe/London:20131207T100000 >>>>>> TRANSP:OPAQUE >>>>>> SUMMARY:Change Event Name >>>>>> DTSTART;TZID=Europe/London:20131207T090000 >>>>>> DTSTAMP:20131214T075411Z >>>>>> SEQUENCE:3 >>>>>> END:VEVENT >>>>>> END:VCALENDAR >>>>>>> 1387007670>HTTP/1.1 406 Not Acceptable >>>>>> Date: Sat, 14 Dec 2013 07:54:30 GMT >>>>>> Strict-Transport-Security: max-age=600 >>>>>> Vary: Accept-Encoding >>>>>> Server: Cyrus/v2.4.17-caldav-beta8 Cyrus-SASL/2.1.23 OpenSSL/0.9.8 >>>>>> zlib/1.2.3 libxml2/2.6.29 SQLite/3.8.2 libical/0.48 >>>>>> Content-Length: 0 >>>>>> >>>>>> >>>>>> I’ll keep looking; I can create and edit events, just not delete them… >>>>>> >>>>>> marty >>>>>> >>>>>> >>>>>>> On 12 Dec 2013, at 17:30, Ken Murchison <mu...@andrew.cmu.edu> wrote: >>>>>>> >>>>>>> Hi Marty, >>>>>>> >>>>>>> Did you find anything related to this? I don't have Mavericks yet, but >>>>>>> maybe a telemetry log of the client trying to delete an entry would >>>>>>> point me in the right direction. >>>>>>> >>>>>>> Worst case, I will be with the Apple client developers in early >>>>>>> February and can test then. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 10/24/2013 07:22 AM, Marty Lee wrote: >>>>>>>> Good afternoon (local time for me!) >>>>>>>> >>>>>>>> Updated my Mac to Mavericks this morning and am now getting the >>>>>>>> following error from >>>>>>>> the CalDAV part of Cyrus when I try to delete an entry. >>>>>>>> >>>>>>>> dav_exec() step: cannot start a transaction within a transaction >>>>>>>> >>>>>>>> Creation & modification works fine, but iCal on the mac now can’t >>>>>>>> delete items. I can work >>>>>>>> around this by using a web interface to my calendars, but I just >>>>>>>> thought I’d mention it here >>>>>>>> that Apple have changed something in iCal with the new version of OS-X. >>>>>>>> >>>>>>>> If I get a chance this weekend, I’ll have a look at the source code >>>>>>>> and see if I can do >>>>>>>> anything to help. >>>>>>>> >>>>>>>> cheers >>>>>>>> >>>>>>>> marty >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- >>>>>>>> Marty Lee e: >>>>>>>> ma...@maui-systems.co.uk >>>>>>>> >>>>>>>> Technical Director v: +44 845 869 2661 >>>>>>>> Maui Systems Ltd f: +44 871 433 8922 >>>>>>>> Scotland, UK w: >>>>>>>> http://www.maui-systems.co.uk >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---- >>>>>>>> Cyrus Home Page: >>>>>>>> http://www.cyrusimap.org/ >>>>>>>> >>>>>>>> List Archives/Info: >>>>>>>> http://lists.andrew.cmu.edu/pipermail/info-cyrus/ >>>>>>>> >>>>>>>> To Unsubscribe: >>>>>>>> >>>>>>>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus >>>>>>> -- >>>>>>> Kenneth Murchison >>>>>>> Principal Systems Software Engineer >>>>>>> Carnegie Mellon University >>>>>> ----- >>>>>> Marty Lee e: ma...@maui-systems.co.uk >>>>>> Technical Director v: +44 845 869 2661 >>>>>> Maui Systems Ltd f: +44 871 433 8922 >>>>>> Scotland, UK w: http://www.maui-systems.co.uk >>>>> -- >>>>> Kenneth Murchison >>>>> Principal Systems Software Engineer >>>>> Carnegie Mellon University >>>>> >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> > ----- > Marty Lee e: ma...@maui-systems.co.uk > Technical Director v: +44 845 869 2661 > Maui Systems Ltd f: +44 871 433 8922 > Scotland, UK w: http://www.maui-systems.co.uk > -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
