Bug 89853

Summary: Sync webdav caldav fails with Status=400
Product: SyncEvolution Reporter: renato filho <renatox>
Component: CalDAV/CardDAVAssignee: SyncEvolution Community <syncevolution-issues>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: medium CC: syncevolution-issues
Version: unspecified   
Hardware: ARM   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: google log
target log

Description renato filho 2015-03-31 20:33:40 UTC
Created attachment 114789 [details]
google log

Trying to sync caldav with google fails with status 400.
Comment 1 renato filho 2015-03-31 20:34:04 UTC
Created attachment 114790 [details]
target log
Comment 2 renato filho 2015-03-31 22:25:48 UTC
I tried on version 1.4 and 1.5 (on Ubuntu trusty and vivid);

works nice on version 1.4 but is broken on 1.5
Comment 3 renato filho 2015-04-01 00:39:57 UTC
works nice with syncevolution from trunk.
Comment 4 Patrick Ohly 2015-04-01 07:06:32 UTC
(In reply to renato filho from comment #3)
> works nice with syncevolution from trunk.

One the same device, using the same settings?

There is one relevant change (see below), but it is hard to tell why it should avoid the issue, or what the issue really is. Because of the low loglevel, the actual request was not in the log. Better run with loglevel=4.

commit 75115022c525d21341be4113d789eccd6e23cca8
Author: Patrick Ohly <patrick.ohly@intel.com>
Date:   Thu Feb 12 13:36:42 2015 +0100

    CalDAV: more efficient "is empty" check (FDO #86335)
    
    Since 1.4.99.4, syncing WebDAV collections always checks first
    whether there are items in the collections. This was partly done for
    slow sync prevention (which is not necessary for empty collections),
    partly for the "is the datastore usable" check.
    
    However, this did not take into account that for CalDAV collections,
    the entire content gets downloaded for this check. That is because
    filtering by item type (VEVENT vs. VJOURNAL) is not implemented
    correctly by all servers. So now all CalDAV syncs, whether incremental
    or slow, always transfered all items, which is not the
    intention (incremental syncs should be fast and efficient).
    
    This commit adds a more efficient isEmpty() check: for simple CardDAV
    collections, only luid and etag get transferred, as in
    listAllItems(). This is the behavior from 1.5.
    
    For CalDAV, a report with a filter for the content type is used and
    the transfer gets aborted after the first item, without actually
    double-checking the content of the item. This is different from
    listAllItems(), which really transfers the content. This extra content
    check would only be needed for some old servers (Radical 0.7) and is
    not essential, because reporting "not empty" even when empty is safe.

commit 7e5638fd904a393d5cc344c075857e3695c7fb80
Author: Patrick Ohly <patrick.ohly@intel.com>
Date:   Thu Feb 12 13:14:59 2015 +0100

    WebDAV: utility class for ne_status
    
    Besides offering C++ wrappers for the C API, this class also ensures
    that memory for the "reason_string" is properly freed.

commit 85df49a68b82000f1429c577fb41cc4259359ee5
Author: Patrick Ohly <patrick.ohly@intel.com>
Date:   Thu Feb 12 13:12:16 2015 +0100

    WebDAV: enhance report handling (status, aborting)
    
    Capture the item status and pass it to the response handler.
    
    Response handlers are allowed to return a non-zero integer when using
    the initAbortingReportParser(), which then aborts processing of the
    response.
    
    This leads to errors being returned by
    ne_xml_dispatch_request(). Session::run() needs to be told if the
    request was aborted, in which case all errors are ignored.
Comment 5 Patrick Ohly 2015-04-01 13:16:53 UTC
I ran the nightly testing again with SyncEvolution 1.5, but could not reproduce the problem.
Comment 6 Patrick Ohly 2015-04-01 13:55:35 UTC
Renato told me that it gets caused by a patch specific (at this time) to Ubuntu - see issue #86463.

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.