[SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command

[Patrick Ohly]

On Wed, 2014-01-15 at 10:34 +0100, Patrick Ohly wrote:
> On Tue, 2014-01-14 at 22:43 +0100, Helge Kraak wrote:
> 
> > [INFO] sync: /org/syncevolution/Session/15596840391389733215:
> > addressbook: started
> > [INFO] sync: /org/syncevolution/Session/15596840391389733215: adding
> > "Jasmin Heinrich"
> > [ERROR] sync: /org/syncevolution/Session/15596840391389733215: error
> > code from SyncEvolution operation not allowed (remote, status 405):
> > PUT: bad HTTP status: <status 1.1, code 405, class 4, Method Not
> > Allowed>
> 
> So that's another issue to look at. You don't need a SyncML client for
> it, just use "--import <file> @webdav addressvbook". For debugging
> purposes, use "SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no
> loglevel=4 --import ...".

Actually, this error is not surprising. As I noticed later while
replying to your email,
database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ is not correct, so the server correctly refuses to create contacts there.

That's another argument in favor of keeping the check during
--configure, because it correctly prevented enabling a source with a
broken config.

Arguably the error messages have to become better. I just don't know
how. Suggestions welcome...

> > [<?xml version="1.0" encoding="utf-8"?>
> > <d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns"
> > xmlns:card="urn:ietf:params:xml:ns:carddav"><d:response><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href><d:propstat><d:prop><card:addressbook-home-set><d:href>/sabredav/addressbookserver.php/addressbooks/admin/</d:href></card:addressbook-home-set><d:alternate-URI-set><d:href>/sabredav/addressbookserver.php/mailto:admin at example.org</d:href></d:alternate-URI-set><d:principal-URL><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href></d:principal-URL><d:group-member-set/><d:group-membership/><d:displayname>Administrator</d:displayname><d:current-user-principal><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href></d:current-user-principal><d:resourcetype><d:principal/></d:resourcetype></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat><d:propstat><d:prop><card:principal-address/><card:addressbook-description/><card:supported-address-data/><card:max-resource-size/></d:prop><d:status>HTTP/1.1 404 Not Found</d:status></d:propstat></d:response></d:multistatus>
> > ]
> 
> It turns out, we were already looking at the URL under which the address
> books are to be found. Because we already looked there, SyncEvolution
> doesn't look again and gives up.
> 
> Where did the
> database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ URL come from? Was it the result of a database discovery done by SyncEvolution?

[...]

> If my hunch is right, then uncommenting the "next.empty()" clause in an
> if check in src/backends/webdav/WebDAV.cpp should fix it:
> 
>             // finally, recursively descend into collections,
>             // unless we identified it as a result (because those
>             // cannot be recursive)
>             if (/* next.empty() && */ !isResult) {
>                 // ^^^^^^^^^^^^^^^^^^
>                 std::string type;
>                 if (props) {
>                     type = (*props)["DAV::resourcetype"];
>                 }
>                 if (type.find("<DAV:collection></DAV:collection>") != type.npos) {

It's not that easy. The "next.empty()" plays a crucial role when
scanning a WebDAV server starting with just the server URL (=
http://example.com/). In that case, we want to go to the principal first
instead of recursively listing all folders on the server.

So the solution in your case might be simple: don't use
database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/

Instead use "syncURL=https://localhost:443/sabredav/" or perhaps even
just "syncURL=https://localhost:443" (if the web server has
either .well-known or principal support at the root). Please let me know
whether --print-databases with that SyncURL works.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.