Bug 318641 - Cal-/CardDAV Resource one-way sync only
Summary: Cal-/CardDAV Resource one-way sync only
Status: RESOLVED NOT A BUG
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: DAV Resource (show other bugs)
Version: 4.10
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL: http://forum.kde.org/viewtopic.php?f=...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-20 18:33 UTC by Tim Drub
Modified: 2013-04-23 22:15 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Drub 2013-04-20 18:33:47 UTC
I run my own server Debian stabel machine  with a lighttpd webserver and SabreDAV as a Web-/Cal-/CardDAV backend. All my clients an devices (iOS, Android, sync-evolution w/Meego, Thunderbird w/Lightining and SoGo conenctor) run fine. 

If i create a DAV resource in Kontact/Akonadi it only writes to the server but nothing is downloaded from the server to Akonadi.





Reproducible: Always

Steps to Reproduce:
1. create DAV resource for carddav or caldav in akonadi
2. use SabreDAV as backend
3. create object in KDE Pim
4. change/create contact from another client
Actual Results:  
Objects created in Kontact are sycnded to the server.
Contacts created/touched by another client are not synced back down to Akonadi.
Existing objects never show up in Kontact.

Expected Results:  
Bi-driectional sync of existing and new objects created on any client.

.xsession-errors only shows one entry:

akonadi_davgroupware_resource_19(2291): Can't find a configured URL, collection.remoteId() is  "akonadi_davgroupware_resource_19"



Server side lighttpd log shows 501 error for REPORT method from KDE

<Source IP> <server> - [19/Apr/2013:21:42:43 +0200] "REPORT /addressbooks/timdrub/default/ HTTP/1.1" 501 357 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) akonadi_davgroupware_resource_19/4.10.0 Safari/534.34"


Other clients e.g. iOS shows 207 status code for REPORT method

<Source IP> <host> [19/Apr/2013:21:20:37 +0200] "REPORT /addressbooks/timdrub/default/ HTTP/1.1" 207 636 "-" "iOS/6.1.3 (10B329) dataaccessd/1.0"
Comment 1 Grégory Oestreicher 2013-04-22 19:28:04 UTC
Hi Tim,

(In reply to comment #0)
> I run my own server Debian stabel machine  with a lighttpd webserver and
> SabreDAV as a Web-/Cal-/CardDAV backend.

Well, I wasn't aware that SabreDAV was available as a standalone solution, I've only seen it integrated in various products, such as ownCloud.

> .xsession-errors only shows one entry:
> 
> akonadi_davgroupware_resource_19(2291): Can't find a configured URL,
> collection.remoteId() is  "akonadi_davgroupware_resource_19"

Not related, this message should not be shown anymore with 4.10.2+.

> Server side lighttpd log shows 501 error for REPORT method from KDE
> 
> <Source IP> <server> - [19/Apr/2013:21:42:43 +0200] "REPORT
> /addressbooks/timdrub/default/ HTTP/1.1" 501 357 "-" "Mozilla/5.0 (X11;
> Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko)
> akonadi_davgroupware_resource_19/4.10.0 Safari/534.34"

Eventually could you enable debug in SabreDAV (no idea if it can be done) as it'll provide more information. Generally errors 5xx are in response to a problem server-side, so here I guess that it choked during the request parsing.
Comment 2 Tim Drub 2013-04-23 10:24:40 UTC
Hi Grégory,

looking at the SabreDAV documentation they recommend using Web Debugging Proxies. Since i couldn't get ZAP to run (I think it didn't like the authentication) I ran Fiddler inside a Windows Virtual machine and had traffic go through it. Here is the result.

This is the request sent from the client:

--- Request BEGIN ---
REPORT https://hostname/addressbooks/timdrub/default/ HTTP/1.1
Host: hostname
Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) akonadi_davgroupware_resource_34/4.10.2 Safari/534.34
Pragma: no-cache
Cache-control: no-cache
Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8
Accept-Encoding: gzip, deflate, x-gzip, x-deflate
Accept-Charset: utf-8,*;q=0.5
Accept-Language: en-US,de;q=0.9,en;q=0.8
Content-Type: text/xml
Depth: 1
Content-Length: 448

<?xml version="1.0" encoding="utf-8"?>
<addressbook-multiget xmlns="urn:ietf:params:xml:ns:carddav">
 <prop xmlns="DAV:">
  <getetag xmlns="DAV:"/>
  <address-data xmlns="urn:ietf:params:xml:ns:carddav">
   <allprop xmlns="DAV:"/>
  </address-data>
 </prop>
 <href xmlns="DAV:">/addressbooks/timdrub/default/asgoYb9ORR.vcf</href>
 <href xmlns="DAV:">/addressbooks/timdrub/default/B353282B-01FF-4F5C-9B8F-9D35DD65FF47.vcf</href>
</addressbook-multiget>
--- Request END ---

And this is the server response

--- Response BEGIN ---
HTTP/1.1 501 Not Implemented
WWW-Authenticate: Basic realm="CalDAV and CardDAV Repository"
Content-Type: text/html
Content-Length: 357
Date: Tue, 23 Apr 2013 09:46:26 GMT
Server: lighttpd/1.4.28

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>501 - Not Implemented</title>
 </head>
 <body>
  <h1>501 - Not Implemented</h1>
 </body>
</html>
--- Response END ---

And this is how it looks like from an iOS client:

-- Request BEGIN ---
REPORT https://hostname/addressbooks/timdrub/default/ HTTP/1.1
Host: hostname
Authorization: Basic Y2hiY2a6MDIxJG2rSUu=
Accept-Encoding: gzip, deflate
Content-Type: text/xml
Accept-Language: de-de
Content-Length: 388
Accept: */*
Connection: keep-alive
Proxy-Connection: keep-alive
User-Agent: iOS/6.1.3 (10B329) dataaccessd/1.0

<?xml version="1.0" encoding="UTF-8"?>
<B:addressbook-multiget xmlns:B="urn:ietf:params:xml:ns:carddav">
  <A:prop xmlns:A="DAV:">
    <A:getetag/>
    <B:address-data/>
  </A:prop>
  <A:href xmlns:A="DAV:">/addressbooks/chack/default/asgoYb9ORR.vcf</A:href>
  <A:href xmlns:A="DAV:">/addressbooks/chack/default/B353282B-01FF-4F5C-9B8F-9D35DD65FF47.vcf</A:href>
</B:addressbook-multiget>
--- Request END ---

And the server response again:

--- Response BEGIN---
HTTP/1.1 207 Multi-status
X-Powered-By: PHP/5.3.3-7+squeeze15
Content-Type: application/xml; charset=utf-8
Vary: Brief,Prefer
Transfer-Encoding: chunked
Date: Tue, 23 Apr 2013 10:11:38 GMT
Server: lighttpd/1.4.28

516
<?xml version="1.0" encoding="utf-8"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav"><d:response><d:href>/addressbooks/chack/default/asgoYb9ORR.vcf</d:href><d:propstat><d:prop><card:address-data>BEGIN:VCARD&#13;
VERSION:3.0&#13;
PRODID:-//Apple Inc.//iOS 6.1.3//EN&#13;
N:West;Test;the;;&#13;
FN:Test the West&#13;
TEL;type=CELL;type=VOICE;type=pref:65432&#13;
REV:2013-04-19T19:20:59Z&#13;
UID:asgoYb9ORR&#13;
END:VCARD&#13;
</card:address-data><d:getetag>"cd0aaa582c9ce9448707d4097a6f80a4"</d:getetag></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response><d:response><d:href>/addressbooks/chack/default/B353282B-01FF-4F5C-9B8F-9D35DD65FF47.vcf</d:href><d:propstat><d:prop><card:address-data>BEGIN:VCARD&#13;
VERSION:3.0&#13;
PRODID:-//Apple Inc.//iOS 6.1.3//EN&#13;
N:man;you are thr;;;&#13;
FN:you are thr man&#13;
EMAIL;type=INTERNET;type=HOME;type=pref:nshiahabja@iisiso.com&#13;
REV:2013-04-19T19:22:28Z&#13;
UID:A05A7F5C-0DFB-4251-BD23-E9A8BE4FA3E0&#13;
END:VCARD&#13;
</card:address-data><d:getetag>"68877951f071e8bb244a41e33192b6a0"</d:getetag></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response></d:multistatus>

0

--- Response END ---


This looks pretty similar to me, only that the tags in the iOS Request are prefixed with A,B, etc. Dunno? What do you think?

Regards
Tim













ZAP - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Fiddler - http://fiddler2.com/
Comment 3 Tim Drub 2013-04-23 10:30:35 UTC
Ah, yes and there is the <allprop> tag inside the <address.data> tag that Akonadi sends but ioS does not.
Comment 4 Evert Pot 2013-04-23 11:10:56 UTC
SabreDAV author here. Just came across this.

The 501 error here is emitted by lighttpd, not sabredav. The request actually never reaches sabredav in this case.

Lighttpd is a notoriously bad webserver. Which is too bad, as it had great promise. At one point development pretty much stopped. I'd highly recommend switching to something like nginx for anything beyond simple websites. DAV is a very complex HTTP application, so you need a webserver that's very compliant ;)
Comment 5 Tim Drub 2013-04-23 18:34:37 UTC
Hi Evert,
thanks for joining the converation.

OK, so I might consider switching the underlying webserver although I don't really understand why it is working for iOS and other clients then.

Please correct me if I am wrong but when its lighttpd throwing that 501 then the problem lies in the header and not the XML payload, right? So which part of the headers is not implemented by lighttpd?

Regards
Tim

PS Latest lighttpd release dates from fall 2012 that's not too bad, is it?
Comment 6 Grégory Oestreicher 2013-04-23 18:44:25 UTC
My best guess would be the Depth header that's the problem. Checking the RFCs it appears that for CalDAV the client SHOULD NOT set it, while for CardDAV the client MUST set it to 0. So in fact none of the above clients are compliant… I'll see for a patch to this.
Comment 7 Tim Drub 2013-04-23 18:49:51 UTC
ok, seems this is related to te missing "Authorization" header in the Akonadi request, see here http://redmine.lighttpd.net/issues/2341

As i am running a conservative Debian server here I am probably on an outdated version of lighttpd (1.4.28).

Gregory, would you expect this to work if littp returned a 401 no authorized?

Thanks for the help.

Regards
Tim
Comment 8 Tim Drub 2013-04-23 18:58:04 UTC
Hi Gregory,

I don't think it is anythig related to CalDAV or CardDAV standards since this is all handled by SabreDAV and not the underlying webserver. Since the 501 comes from lighttpd I doubt it's the "Depth" header.
 
I'd say I need to get a newer version running, though I am. ot sure when I'll find the time to do that.  Thanks for your help and sorry for bringing up this false positive.

Regards
Tim
Comment 9 Grégory Oestreicher 2013-04-23 19:00:50 UTC
(In reply to comment #7)
> ok, seems this is related to te missing "Authorization" header in the
> Akonadi request, see here http://redmine.lighttpd.net/issues/2341

Nice find! It's indeed likely you have the same issue.

> Gregory, would you expect this to work if littp returned a 401 no authorized?

As this works this way with other web servers I'd say yes.

(In reply to comment #8)
> I don't think it is anythig related to CalDAV or CardDAV standards since
> this is all handled by SabreDAV and not the underlying webserver. Since the
> 501 comes from lighttpd I doubt it's the "Depth" header.

Indeed. However as this behavior is not RFC-compliant it's always better to fix it.

Cheers,
Grégory
Comment 10 Tim Drub 2013-04-23 21:27:19 UTC
Hi,

just fyi:

Updated the server from Debian stable to testing and thus lighttpd got updated to 1.4.31.
Everything works now.

Thanks again for the help.

Regards
Tim
Comment 11 Evert Pot 2013-04-23 22:15:17 UTC
Great to hear it :) btw: MKCALENDAR may still not work without patching lighttpd :

http://redmine.lighttpd.net/issues/2346#change-8020