[CalendarServer-users] Modifying entries fails with
evolution-2.6 due to wrong etag
Wilfredo Sánchez Vega
wsanchez at wsanchez.net
Tue Sep 19 12:13:24 PDT 2006
On Sep 19, 2006, at 11:27 AM, Cyrus Daboo wrote:
> Well of course there has been much debate about the CalDAV specs
> definition of what servers should do on PUT. CalDAV says that a
> server SHOULD return a strong ETag when PUT does not change the
> data being stored (which is currently always the case with our
> server - but may not always be true in future). Clients then know
> that if they get back a strong ETag, there was no modification of
> the data on the server and hence no need to follow the PUT with an
> immediate GET to see what changed. In the absence of a strong ETag,
> a good client ought to GET the data it just stored with its new
> ETag just to stay in sync.
a) I still disagree with the idea of putting ETag hooey into CalDAV.
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.
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2746 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20060919/d246b5ec/smime.bin
More information about the calendarserver-users