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:[email protected]</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:re sponse></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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
