Adding a CardDav resource works fine, and syncs server changes without any issue, but making any change locally doesn't sync to server and syncing stops working. I posted at site's forum (whose carddav I am using) and here's what they posted: It fetches server updates and creates contacts locally fine, but editing an existing contact and then saving the changes fails. From the server log: ------------- 2015-01-22T05:43:30.115405-05:00 imap30 sloti30t15/httpd[3825938]: frontend1.nyi.internal [10.202.2.160] as "robntest@fastmail.fm" with "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.14.2 (like Gecko) Konqueror/4.14"; "PUT /dav/addressbooks/user/robntest@fastmail.fm/Default/1421922962.R393.vcf HTTP/1.0" => "412 Precondition Failed" ------------- 412 usually means the client saying "apply this change, but only if the object hasn't changed since I was last here". So looking at a traffic dump: ------------- PUT /dav/addressbooks/user/robntest@fastmail.fm/Default/1421922962.R393.vcf HTTP/1.0 ... If-match: "acaee90b9e5aa12c893af0a199b8ff62a9e9653f" ... BEGIN:VCARD ... ------------- So its saying "replace this object, but only if the old version has this tag". But, in the request immediately before this one: ------------- REPORT /dav/addressbooks/user/robntest@fastmail.fm/Default/ HTTP/1.0 ... HTTP/1.1 207 Multi-Status ... <X764:href>/dav/addressbooks/user/robntest@fastmail.fm/Default/1421922962.R393.vcf</X764:href> <X764:propstat> <X764:prop> <getetag>"0eb7456d4bc7e1322b8c9b53f43ea7bfc693fc58"</getetag> <address-data><![CDATA[BEGIN:VCARD ... ------------- That's different. So this really seems like a client problem - its got an older tag stored somewhere and managed to not update it with the new one, even though it asked for it! Reproducible: Always Steps to Reproduce: 1. Add a CardDav Resource 2. Wait for it to sync initially 3. Change any contact.
Hi, I'm from FastMail, and I wrote the above on another forum when Aqeel asked me about it. This is using FastMail CardDAV. If you want to try it, create a trial account at fastmail.com, then go to https://www.fastmail.com/go/carddavbeta to enable CardDAV for your account. There's server settings at https://beta.fastmail.com/help/technical/servernamesandports.html. Just to add to the issue, the ETag that it the client is during the PUT is one it obtained earlier from a GET. The REPORT was in a response to an explicit sync request (F5 in kaddressbook). It updated the contact, but doesn't appear to have updated the stored etag. I'll need to do more testing to see the exact order of events. I'm not sure when I'll get to that testing; hopefully today. It should be easy for you to reproduce though.
I think this is a duplicate of bug #338570.
Hey, Yup, it's indeed the same issue as for #338570. Merging, and it's fixed for 4.4.10 normally. Cheers, Grégory *** This bug has been marked as a duplicate of bug 338570 ***