[CalendarServer-users] Modifying entries fails with evolution-2.6 due to wrong etag

[Wilfredo Sánchez Vega]

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.

   Right, but:

   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  
subclasses.

> 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.

	-wsv

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2746 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20060919/d246b5ec/smime.bin