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

Wilfredo Sánchez Vega wsanchez at wsanchez.net
Tue Sep 19 11:03:18 PDT 2006

   Well, Twisted is doing that on purpose, and even has a unit test  
checking for it.

   Here's what's going on, and this is a known problem.  Like Apache,  
when we return an ETag for a resource, if the resource was created in  
the current second, we return a weak ETag.  Past that initial one- 
second (or less) window, the ETag becomes a strong ETag.

   This has been a subject of much debate on the WebDAV mailing lists  
for a while now.  One problem is that the behavior of returning ETag  
in response to a PUT request isn't specified by HTTP.  The actual  
problem in our case is that we use the time stamp (with a one-second  
resolution) to compute the ETag, and therefore don't necessarily have  
a valid ETag in the first second (the file can change again in that  
second and we'd have no way to know).

   So Evolution does a PUT or it does (a GET immediately after a  
resource is created) and gets back a weak ETag, and it later tries to  
use that in a PUT, to which the server dutifully that the ETag is now  

   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.


On Sep 16, 2006, at 7:34 AM, Guido Guenther wrote:

> Hi,
> when trying to modify an already defined date with evolution 2.6 I  
> get:
> Evolution:
> If-Match: W/"5005B-3D3-450BE897"
> Server:
> HTTP/1.1 412 Precondition Failed
> Date: Sat, 16 Sep 2006 13:13:53 GMT
> DAV: 1, access-control, calendar-access, calendar-schedule
> Content-Type: text/html
> Content-Length: 157
> Server: Twisted/2.4.0 TwistedWeb/[twisted.web2, version 0.2.0]  
> TwistedCalDAV/unknown
> <html><head><title>Precondition Failed</title></ 
> head><body><h1>Precondition Failed</h1><p>Requested resource does  
> not have a matching ETag.</p></body></html>
> This is due to the fact that matchEtag fails. The etags match but not
> the allowWeak flag. This patch lets evolution update entries:
> --- twisted/web2/http.py.orig 2006-09-16 16:01:13.000000000 +0200
> +++ twisted/web2/http.py	2006-09-16 16:23:12.000000000 +0200
> @@ -253,7 +255,7 @@
>      # If either one fails, we return PRECONDITION_FAILED
>      match = request.headers.getHeader("if-match")
>      if match:
> -        if not matchETag(match, False):
> +        if not matchETag(match, True):
>              raise HTTPError(StatusResponse 
> (responsecode.PRECONDITION_FAILED, "Requested resource does not  
> have a matching ETag."))
>      unmod_since = request.headers.getHeader("if-unmodified-since")
> But I'm not sure that's what's intended. Who's at fault here evo or  
> the
> server?
> Cheers,
>  -- Guido
> _______________________________________________
> calendarserver-users mailing list
> calendarserver-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/calendarserver-users

-------------- 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/ff2f14f9/smime-0001.bin

More information about the calendarserver-users mailing list