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 <murch@xxxxxxxxxxxxxx> 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 <murch@xxxxxxxxxxxxxx> 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:
>>>>> marty@xxxxxxxxxxxxxxxxxx
>>>>>
>>>>> 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: marty@xxxxxxxxxxxxxxxxxx
>>> 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
----
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
