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"
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.
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 VERSION:3.0 PRODID:-//Apple Inc.//iOS 6.1.3//EN N:West;Test;the;; FN:Test the West TEL;type=CELL;type=VOICE;type=pref:65432 REV:2013-04-19T19:20:59Z UID:asgoYb9ORR END:VCARD </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 VERSION:3.0 PRODID:-//Apple Inc.//iOS 6.1.3//EN N:man;you are thr;;; FN:you are thr man EMAIL;type=INTERNET;type=HOME;type=pref:nshiahabja@iisiso.com REV:2013-04-19T19:22:28Z UID:A05A7F5C-0DFB-4251-BD23-E9A8BE4FA3E0 END:VCARD </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/
Ah, yes and there is the <allprop> tag inside the <address.data> tag that Akonadi sends but ioS does not.
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 ;)
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?
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.
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
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
(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
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
Great to hear it :) btw: MKCALENDAR may still not work without patching lighttpd : http://redmine.lighttpd.net/issues/2346#change-8020