[CalendarServer-users] Modifying entries fails with
evolution-2.6 due to wrong etag
cdaboo at apple.com
Tue Sep 19 12:26:52 PDT 2006
--On September 19, 2006 12:13:24 PM -0700 Wilfredo Sánchez Vega
<wsanchez at wsanchez.net> wrote:
> a) I still disagree with the idea of putting ETag hooey into CalDAV.
It is a bone of contention!
> b) We don't have a strong ETag to return at the end of a PUT unless we
> do the equivalent of sleep(1) first.
Right - getting 'true' strong etags is the first step.
> c) Right now we're using logic
> that lived in web2.dav, not twistedcaldav, so CalDAV's rules don't apply.
> See (a), which basically requires us to override the ETag logic in the
> CalDAV subclasses.
But we already have to override the PUT/COPY/MOVE behavior to cope with
CalDAV semantics for calendar data so its not much of a stretch to special
case ETag behavior there.
In any case, at the end of the day I think it will ultimately be up to the
client folks to say what they really want in terms of ETag-based
>> One alternative to the weak ETag issue, though, would be to not use
>> computed ETags and instead cache a (definitely) unique ETag as a
>> private property of the resource. The server then reads/writes that
>> value as appropriate and it can always be a strong ETag.
> Well, that ETag has to be computed at some point.
> We could use a checksum as an ETag (and also then include the checksum
> header). Computing checksums isn't super cheap, but that may be OK if
> it's just at creation time.
> You might think an increasing integer would work, but that doesn't
> work if a resource is deleted and then re-added, unless we're somehow
> going to cache the ETags even after deletion.
A hash of timestamp+uri+counter would suffice if counter were 'global' and
could be atomically updated without too much overhead.
The other option - a hash of the actual resource data - is not cheap, but
does have the benefit that PUT'ing exactly the same data on top of an
existing resource will not change the ETag. But I don't think we need to
optimize for that case per se.
More information about the calendarserver-users