google-calendar-apicaldavgoogle-calendar-reminders

How to find out if VAlarm changed for an Event in CalDav?

While playing with Google Calendar and CalDav i realized that if for a given event you modify a notification (Alarm), the event's ETag won't change.

Now, comparing ETags is essential to find out when a given event changes (in CalDav).

The request i am using to find out the ETag is 

<?xml version=\"1.0\" encoding=\"utf-8\"?><d:propfind xmlns:d=\"DAV:\" xmlns:cs=\"http://calendarserver.org/ns/\"><d:prop><d:getetag /></d:prop></d:propfind>

Which would return something like

<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:caldav="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:ical="http://apple.com/ns/ical/">

  <D:response xmlns:carddav="urn:ietf:params:xml:ns:carddav" xmlns:cm="http://cal.me.com/_namespace/" xmlns:md="urn:mobileme:davservices">
    <D:href>/caldav/v2/myemail@gmail.com/events/</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>

  <D:response xmlns:carddav="urn:ietf:params:xml:ns:carddav" xmlns:cm="http://cal.me.com/_namespace/" xmlns:md="urn:mobileme:davservices">
    <D:href>/caldav/v2/myemail%40gmail.com/events/xqrjsgs1gj35cpub2nnumntm5j%40google.com.ics</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
        <D:getetag>"63723144835"</D:getetag>
      </D:prop>
    </D:propstat>
  </D:response>

</D:multistatus>

Now, after you go and modify the notification of that event in Google Calendar you still keep getting the same ETag:

<D:getetag>"63723144835"</D:getetag>

Is there anything else i might look for in order to find out when a notification/Alarm changes in an event? or, am i doing anything wrong?

Solution

  • This definitely sounds like a bug/protocol violation on the Google CalDAV implementation side:

    1. CalDAV specifies that servers should use strong tags: https://www.rfc-editor.org/rfc/rfc4791#section-5.3.4
    2. Strong etags correspond pretty much to bit to bit comparison: https://www.rfc-editor.org/rfc/rfc2616#section-13.3.3
    3. Even if there were good reasons for returning a weak etag, what you get back (e.g. "63723144835") does not correspond to a weak etag syntax. Should look like "W/63723144835" (see https://www.rfc-editor.org/rfc/rfc2616#section-3.11 )

    With all that said, you should really consider using WebDAV Sync ( https://www.rfc-editor.org/rfc/rfc6578 ) to monitor changes in a given calendar collection. I would be very surprised if the Google Calendar Server exposed the same issue when using sync.