[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Inf-IT DAVcl] Android synching problem (again)


On 03/05/2014 10:43 AM, Ján Máté wrote:
Hi Johan,

On 05 Mar 2014, at 16:25, Johan Vromans <jvromans@xxxxxxxxxxx> wrote:

Marten Gajda <marten@xxxxxxxx> writes:

Which client created the event initially?
 From the OP:

The appointment is a repeating event, to repeat every two weeks.
Starting tomorrow. Ending 2014-12-31. The appointment exists on all
clients. It is displayed in weeks 10, 12, and so on.

Using CalDAVzap I edit the first occurrence of the appointment and
change all occurrences: change the starting date to one week later. It
is now displayed in weeks 11, 13, and so on.
So the suspect is CalDAVzap. But it could very well be the case that the
appointment already was corrupt (in some way) at that time and that the
changes I made just made the corruption apparent.

Anyone has a tool to verify ics files for correctness?

Also, it would be very helpful if there was an (easy) was to show the
raw event (ics) data (or copyable url) from CalDAVzap...
if you click to "inspect element" in the browser you will see the URL of the
"inspected" event ...

If it is possible please try to reproduce the problem and send us the steps
you performed.

Its very easy to reproduce:

1. Create a recurring event, say daily for 7 instances
2. Edit the middle instance, selecting "This and all future" and change the time

The telemetry below show what it looks like on my server, which rejects the resource as invalid (multiple VEVENT with different UIDs). Note that I stripped the VTIMEZONEs for brevity.

If you want to split the instances like this, they need to be put back as separate resources. Or you can use the same UID and have the second VEVENT be linked to the first with RECURRENCE-ID (see RFC 5545, section 3.8.4.4)


PUT /dav/calendars/user/ken/339B1B76-FAA8-4792-B829-FF74D6E8F5E1/e5a
9973885faad790705afdc3a84eca74c08f849eef105f61cac4a8af21bc598.ics HTTP/1.1
Accept-encoding: gzip, deflate
Content-type: text/calendar; charset=UTF-8
Accept-language: en-US,en;q=0.5
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
Host: localhost
Accept: text/plain, */*; q=0.01
X-client: CalDavZAP 0.9.42 (Inf-IT CalDAV Web Client)
Connection: keep-alive
Content-length: 5494
If-none-match: *
X-requested-with: XMLHttpRequest
Authorization: Basic ...
Referer: http://localhost/caldavzap-0.10.0rc4/

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
BEGIN:VEVENT
CREATED:20140305T224655Z
LAST-MODIFIED:20140305T224655Z
DTSTAMP:20140305T224655Z
UID:f0cr1lsr-n01t-ba84-mf6p-ee7brhb3lr2i
SUMMARY:asdasdasda
RRULE:FREQ=DAILY;COUNT=7
TRANSP:OPAQUE
CLASS:PUBLIC
DTSTART;TZID=America/New_York:20140305T080000
DTEND;TZID=America/New_York:20140305T090000
END:VEVENT
PRODID:-//Inf-IT//CalDavZAP 0.9.42//EN
END:VCALENDAR

HTTP/1.1 201 Created
Keep-Alive: timeout=60
Connection: Keep-Alive
Date: Wed, 05 Mar 2014 22:46:55 GMT
Cache-Control: no-cache
Vary: Accept-Encoding
Server: Cyrus/git2.4.17-caldav-beta9+78 (Murder) Cyrus-SASL/2.1.26 OpenSSL/1.0.1e zlib/1.2.7 libxml2/2.9.1 SQLite/3.7.13 libical/0.48 Jansson/2.4
ETag: "dbb8c1330bbc553df2c508a2c52b7a725e240820"
Last-Modified: Wed, 05 Mar 2014 22:46:55 GMT
Content-Length: 0


PUT /dav/calendars/user/ken/339B1B76-FAA8-4792-B829-FF74D6E8F5E1/e5a
9973885faad790705afdc3a84eca74c08f849eef105f61cac4a8af21bc598.ics HTTP/1.1
Accept-encoding: gzip, deflate
Content-type: text/calendar; charset=UTF-8
Accept-language: en-US,en;q=0.5
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
Host: localhost
Accept: text/plain, */*; q=0.01
X-client: CalDavZAP 0.9.42 (Inf-IT CalDAV Web Client)
Connection: keep-alive
Content-length: 743
If-match: "dbb8c1330bbc553df2c508a2c52b7a725e240820"
X-requested-with: XMLHttpRequest
Authorization: Basic ...
Referer: http://localhost/caldavzap-0.10.0rc4/

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
BEGIN:VEVENT
CREATED:20140305T224655Z
LAST-MODIFIED:20140305T224655Z
DTSTAMP:20140305T224655Z
UID:f0cr1lsr-n01t-ba84-mf6p-ee7brhb3lr2i
SUMMARY:asdasdasda
RRULE:FREQ=DAILY;COUNT=3
TRANSP:OPAQUE
CLASS:PUBLIC
DTSTART;TZID=America/New_York:20140305T080000
DTEND;TZID=America/New_York:20140305T090000
END:VEVENT
BEGIN:VEVENT
CREATED:20140305T224655Z
LAST-MODIFIED:20140305T224755Z
DTSTAMP:20140305T224755Z
UID:gcko6hrs-5n1l-t71l-xadx-cj667j4r0rey
SUMMARY:asdasdasda
RRULE:FREQ=DAILY;COUNT=4
TRANSP:OPAQUE
CLASS:PUBLIC
DTSTART;TZID=America/New_York:20140308T100000
DTEND;TZID=America/New_York:20140308T110000
END:VEVENT
PRODID:-//Inf-IT//CalDavZAP 0.9.42//EN
END:VCALENDAR

HTTP/1.1 403 Forbidden
Keep-Alive: timeout=60
Connection: Keep-Alive
Date: Wed, 05 Mar 2014 22:47:55 GMT
Cache-Control: no-cache
Vary: Accept-Encoding
Server: Cyrus/git2.4.17-caldav-beta9+78 (Murder) Cyrus-SASL/2.1.26 OpenSSL/1.0.1e zlib/1.2.7 libxml2/2.9.1 SQLite/3.7.13 libical/0.48 Jansson/2.4
Content-Type: application/xml; charset=utf-8
Content-Length: 153

<?xml version="1.0" encoding="utf-8"?>
<D:error xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <C:valid-calendar-object-resource/>
</D:error>

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University


Follow-Ups:
Re: [Inf-IT DAVcl] Android synching problem (again)Ján Máté <jan.mate@xxxxxxxxxx>
References:
[Inf-IT DAVcl] Android synching problem (again)Johan Vromans <jvromans@xxxxxxxxxxx>
Re: [Inf-IT DAVcl] Android synching problem (again)Marten Gajda <marten@xxxxxxxx>
Re: [Inf-IT DAVcl] Android synching problem (again)Johan Vromans <jvromans@xxxxxxxxxxx>
Re: [Inf-IT DAVcl] Android synching problem (again)Marten Gajda <marten@xxxxxxxx>
Re: [Inf-IT DAVcl] Android synching problem (again)Johan Vromans <jvromans@xxxxxxxxxxx>
Re: [Inf-IT DAVcl] Android synching problem (again)Ján Máté <jan.mate@xxxxxxxxxx>