| Summary: | Cal-/CardDAV Resource one-way sync only | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Tim Drub <tim.drub> |
| Component: | DAV Resource | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | evertpot, greg |
| Priority: | NOR | ||
| Version: | 4.10 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| URL: | http://forum.kde.org/viewtopic.php?f=215&t=110883 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Tim Drub
2013-04-20 18:33:47 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. 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 |