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

Cyrus Daboo cdaboo at apple.com
Tue Sep 19 11:27:34 PDT 2006


Hi Wilfredo,

--On September 19, 2006 11:03:18 AM -0700 Wilfredo Sánchez Vega 
<wsanchez at wsanchez.net> wrote:

>    The server behavior in returning the PRECONDITION_FALED response is
> correct, so this patch isn't.  What we probably need to do in web2.dav is
> stop issuing ETags on PUT at all, given that the HTTP spec doesn't define
> what this means.  We also need a better solution for the first-second
> problem, which may mean that we omit ETags in responses where we current
> issue weak tags, or figure out a better way to compute strong tags.

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.

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.

-- 
Cyrus Daboo



More information about the calendarserver-users mailing list