Hi I have been using multiple clients (different iCal version 4.0.4, 5.0.3) and different system and just created a new account to try to make sure... it's the same problem...
It's not just for Deletes I have to do all operations twice... If I refresh iCal before each Move, Delete, etc... then it is ok, but not ideal solution. On 2013-03-07, at 12:09 PM, Cyrus Daboo wrote: > Hi Robert, > > --On March 7, 2013 at 12:04:56 PM -0500 Robert Bruce <rbr...@celsiusinc.com> > wrote: > >> ::ffff:192.168.1.38 - - [07/Mar/2013:12:03:02 -0400] "DELETE >> /calendars/__uids__/admin/calendar/AE195B52-8AD1-4F43-BB6B-2298EC72E889.i >> cs HTTP/1.1" 412 157 "-" "DAVKit/4.0.3 (732.2); CalendarStore/4.0.4 >> (997.7); iCal/4.0.4 (1395.7); Mac OS X/10.6.8 (10K549)" i=1 or=1 t=12.7 >> ::ffff:192.168.1.38 - admin [07/Mar/2013:12:03:02 -0400] "GET >> /calendars/__uids__/admin/calendar/AE195B52-8AD1-4F43-BB6B-2298EC72E889.i >> cs HTTP/1.1" 200 705 "-" "DAVKit/4.0.3 (732.2); CalendarStore/4.0.4 >> (997.7); iCal/4.0.4 (1395.7); Mac OS X/10.6.8 (10K549)" i=1 or=1 t=22.4 >> >> >> >> >> Second try delete works... >> >> >> >> ::ffff:192.168.1.38 - admin [07/Mar/2013:12:03:51 -0400] "DELETE >> /calendars/__uids__/admin/calendar/AE195B52-8AD1-4F43-BB6B-2298EC72E889.i >> cs HTTP/1.1" 204 0 "-" "DAVKit/4.0.3 (732.2); CalendarStore/4.0.4 >> (997.7); iCal/4.0.4 (1395.7); Mac OS X/10.6.8 (10K549)" i=1 or=1 t=511.1 >> >> >> >> >> The deletes that work are not followed by a GET... >> > > OK, so the client is doing a conditional DELETE request - i.e. it is asking > the server to only do the DELETE if the resource on the server is unchanged > from the one that the client originally cached. For some reason it is not, so > a 412 error comes back, and the client reloads the resource using GET. The > second DELETE then works fine. > > Is the account in your client one that has been present all the time since > you did the upgrade? If so, try removing the account from the client, then > re-add it and let it resync all the data. Once it has done that, hopefully it > will have the change state correctly cached and you won't see the double > DELETEs (except for when a real change has taken place on the server that the > client has not sync'd). > > -- > Cyrus Daboo _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
