Bug 77424 - VJOURNAL: handle UID uniqueness error message
Summary: VJOURNAL: handle UID uniqueness error message
Status: RESOLVED MOVED
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: CalDAV/CardDAV (show other bugs)
Version: 1.4
Hardware: Other All
: low enhancement
Assignee: SyncEvolution Community
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-14 10:02 UTC by Patrick Ohly
Modified: 2018-10-13 12:41 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Patrick Ohly 2014-04-14 10:02:39 UTC
Apple Calendar server refuses to create a new VJOURNAL item if the UID is not unique. This started happening in nightly testing when introducing POST support. Before that, SyncEvolution would automatically use the same URL for old and new item and therefore detect the conflict and return "was merged" - see:

http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-4-1/testing-amd64/20-apple/Client_Source_apple_caldavtodo_testInsertTwice.log.html

When PUT fails, we get a "code 412, class 4, Precondition Failed" error which triggers a search for the UID.

When POST fails, we get a very less specific "code 403, class 4, Forbidden" error back with more details in the XML body:

[DEVELOPER 00:00:14] stderr: Read block (364 bytes):
[DEVELOPER 00:00:14] stderr: [<?xml version='1.0' encoding='UTF-8'?>
[DEVELOPER 00:00:14] stderr: <error xmlns='DAV:'>
[DEVELOPER 00:00:14] stderr:   <no-uid-conflict xmlns='urn:ietf:params:xml:ns:caldav'>
[DEVELOPER 00:00:14] stderr:     <href xmlns='DAV:'>/calendars/__uids__/user01/tasks/c5490e736b6836c4d353d98bc78b3a3d.ics</href>
[DEVELOPER 00:00:14] stderr:   </no-uid-conflict>
[DEVELOPER 00:00:14] stderr:   <error-description xmlns='http://twistedmatrix.com/xml_namespace/dav/'>UID already exists</error-description>
[DEVELOPER 00:00:14] stderr: </error>]
[DEVELOPER 00:00:14] stderr: Running post_send hooks
[DEVELOPER 00:00:14] stderr: ah_post_send (#0), code is 403 (want 401), WWW-Authenticate is (none)
[DEVELOPER 00:00:14] stderr: Request ends, status 403 class 4xx, error line:
[DEVELOPER 00:00:14] stderr: 403 Forbidden
[DEBUG 00:00:14] POST: bad HTTP status: <status 1.1, code 403, class 4, Forbidden>, must not retry

The current handling of that is to do the same UID search, just in case that a UID conflict might be the reason. It would be better to parse the XML body and save the roundtrip time for the search.

Probably not that important, though.
Comment 1 GitLab Migration User 2018-10-13 12:41:33 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/67.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.