GNOME Bugzilla – Bug 704740
WebDAV - Do not store ETag into REV attribute
Last modified: 2013-09-21 13:37:31 UTC
ETag is opaque alphanumeric sent by the server to the client, then sent back to the server on PUT (modify a contact). REV is a timestamp per specification (thans mcrha: "the spec really says it's supposed to be a timespamp, not any other data type: http://tools.ietf.org/html/rfc6350#section-6.7.4" ). And davical expect so to the point it store REV as modified field in the database tables, set as TIMESTAMP type ... thus when it gets REV as a non timestamp by gnome-contacts or other evolution data server users, it breaks and no changes are lost in translation. My investigations at that point, shows that ETag needs to be stored in some way by evolution data server , for the session only. Ie if we store it in the vcard via any other field, and the server upgrade change the generation of the ETag (davical does an md5 of the raw vcard but other might use another calculus), then we would loose sync. But we need to store it in some way: I am looking at soup session, or if a session object in evolution data server itself we could use it. ETag is just like light cookies .
Confirming, the WebDAV backend stores the ETag into REV field.
Created attachment 249892 [details] [review] eds patch for evolution-data-server; Do not store ETag into REV in WebDAV. If you can, please give it a try, as I cannot fully test it (against DAViCal), but I see on my server that the REV is left as is and the backend uses the new attribute, thus it should work fine for DAViCal as well.
Works very well. Thanks ! I tested via gnome-contacts (jhbuild of gnome 3.9) to davical 1.1.1 (debian). The test was to change the fullname of an existing contact.
Thanks for the testing. Created commit 198bcea in eds master (3.9.5+) Created commit 749de2b in eds gnome-3-8 (3.8.5+)