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
signature.asc
Description: Message signed with OpenPGP using GPGMail
---- 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
