Skip to content

caldav, carddav: support the CalendarServer getctag property#208

Open
kanocz wants to merge 1 commit into
emersion:masterfrom
kanocz:getctag
Open

caldav, carddav: support the CalendarServer getctag property#208
kanocz wants to merge 1 commit into
emersion:masterfrom
kanocz:getctag

Conversation

@kanocz

@kanocz kanocz commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

Summary

Add optional support for the getctag property from the CalendarServer extension
namespace (http://calendarserver.org/ns/). getctag is an opaque collection-level
token that changes whenever the collection's contents change, letting clients
(DAVx5, Apple, etc.) detect "did anything change?" with a single PROPFIND on the
collection instead of enumerating every member's ETag. It's widely supported and
is the change-detection fallback for clients that don't use sync-collection.

Change

  • Add a CTag string field to caldav.Calendar and carddav.AddressBook.
  • Add the internal.GetCTag element, internal.GetCTagName, and a
    CalendarServerNamespace constant.
  • In propFindCalendar / propFindAddressBook, report getctag when CTag is
    non-empty.

When CTag is empty (the default), the property is omitted entirely, so existing
backends are unaffected.

Notes

  • Although the property lives in the "calendarserver" namespace, the same
    property/namespace is also used for CardDAV address books (per the CalendarServer
    convention and as implemented by SabreDAV / dav4jvm / Apple). The shared
    internal.GetCTag reflects that; a clarifying comment is included in the code.

Add a CTag field to Calendar and AddressBook. When set, the server reports it as
the http://calendarserver.org/ns/ getctag property in PROPFIND, which clients
(e.g. DAVx5, Apple) use to detect collection changes without enumerating every
member's ETag. An empty CTag (the default) omits the property, preserving
existing behavior.
@emersion

Copy link
Copy Markdown
Owner

I'm not super keen about adding support for non-standard extensions. Clients should upgrade to RFC 6578.

@kanocz

kanocz commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

It's "non standart", but de facto is... Apple introduced it and most third-party dav-clients uses it... and this allow to significantly reduce traffic and load on synchronization of big collection

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants