"No CardDAV/CalDAV service" for DAViCal 0.6+

DAVx⁵
Log in to reply
  • A

    When trying to setup a davdroid account with my davical server I get stuck between a rock and a hard place:

    • the url
      http://
      <servername>/davical/caldav.php/<user>
      username
      password
      no preemptive auth
      is accepted.
      Data is retrieved from server but no addressbooks or calendars are offered.

    Now for this issue I should provide a log. I can’t because at the above step I am stuck. No account means no debugging option.

    I’d prefer to see that Davdroid gets more robust and will offer proper settings by itself. I’d rather see a selection of supported Caldav servers a proper version check and initial negotiation that shows something like “yes you are on the right track”. It is far too tedious to enter the url details over and over just to find out that nothing works (which is what i really wanted to send as an issue - but unfortunately with the latest version I don’t event get to setting up an account). So please stay tuned for my real issue report after we are over this one …

    So first you might want to add an option to make the password visible. When the server was sucessfully connnected to there should be some information about the server. Then if there are no calendars and addressbooks found this should be flagged as an error and the software should not just get stuck.

    0
  • R
    developer

    Thanks for your issue report. I’ll answer it frankly:

    Now for this issue I should provide a log. I can’t because at the above step I am stuck. No account means no debugging option.

    Please read How to view the logs. “Not requires for problems while adding an account.” → Debugging options are always active when adding the account because there’s no GUI available yet to enable them.

    I’d prefer to see that Davdroid gets more robust and will offer proper settings by itself.

    DAVdroid can’t know “proper” settings because every CardDAV/CalDAV service is different. There are standardized mechanisms to determine paths and capabilities, and our aim is to use these mechanisms. If your server uses Well-Known Paths, you just need to enter the domain (maybe uncheck Preemptive Auth) and you’re done.

    I’d rather see a selection of supported Caldav servers

    We won’t store profiles of known or supported serves. Every server that correctly implements CalDAV/CardDAV and resource auto-detection is supported; if it’s not, its a bug either in DAVdroid or at the server-side. In the first case we will try to fix it, in the latter case the server manufacturers should do so.

    a proper version check

    What do you mean by “version check”? Do you really think it’s wise to keep 20 services * 10 versions = 200 profiles of services with different paths and settings and then still just be able to cover the default settings? Are you going to maintain these profiles for us?

    It is far too tedious to enter the url details over and over just to find out that nothing works (which is what i really wanted to send as an issue - but unfortunately with the latest version I don’t event get to setting up an account).

    DAVdroid is not a server debugging tool. (We have planned to write an online CalDAV/CardDAV service checker somewhen but yes, we don’t have much time at the moment.) If you don’t know whether your server works and how its settings are, please use another non-mobile client, curl or whatever to test your server. As soon as your server works (and for instance Well-Known URLs are set up), enter the domain in DAVdroid and it should work. If it does not, there are still logs.

    So please stay tuned for my real issue report after we are over this one …

    Please just send the logs.

    So first you might want to add an option to make the password visible.

    Please open a new issue for that, describing why that is necessary. It’s just work and I don’t see a reason for it.

    When the server was sucessfully connnected to there should be some information about the server.

    It’s intentionally that users aren’t bothered with technical details. If they’re power users, they know how to configure and debug a configuration; if they’re not, the details are useless for them anyway.

    Then if there are no calendars and addressbooks found this should be flagged as an error and the software should not just get stuck.

    I don’t know what you mean by “getting stuck”. If neither CalDAV nor CardDAV is supported by the server, DAVdroid shows an error message. If CalDAV and/or CardDAV is supported, a dialog with the available collections is shown. If there are no available collections, the list will be empty.

    0
  • A

    I have the same problem(s) with davdroid and davical…
    In 0.6.0 davical did not see any CalDAV or CardDAV capabilities:
    Invalid DAV response: Weder CalDAV noch CardDAV ist verfügbar.
    In 0.6.1 davical I get to the page asking me to select the calendars and addressbooks, I want to sync, but there are none to select.
    With 0.5.14-alpha i can setup Accounts with the same Server.
    I posted a log of all three versions in a gist:
    https://gist.github.com/kaindl/347a003b902891adc5a2

    My Server is working very well with KOrganizer/Kontact, I did not try other clients for now.

    Hope this helps…

    0
  • R
    developer

    I posted a log of all three versions in a gist:
    https://gist.github.com/kaindl/347a003b902891adc5a2

        D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "PROPFIND /.well-known/carddav HTTP/1.1[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "Content-Type: text/xml; charset=UTF-8[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "Depth: 0[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "Content-Length: 88[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "Host: calendar.testdomain.tld[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "Connection: Keep-Alive[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "User-Agent: DAVdroid/0.6.1[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "Authorization: Basic c2FicmluYTp0ZXN0[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "<propfind xmlns="DAV:">[\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "   <prop>[\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "      <current-user-principal/>[\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "   </prop>[\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 >> "</propfind>"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 << "HTTP/1.1 302 Moved Temporarily[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 << "Server: nginx/1.4.7[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 << "Date: Wed, 30 Jul 2014 22:15:43 GMT[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 << "Content-Type: text/html[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 << "Content-Length: 160[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 << "Connection: close[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-0 << "Location: http://calendar.testdomain.tld/caldav.php/.well-known/carddav[\r][\n]"

    The /.well-known/carddav URL redirects to http://calendar.testdomain.tld/caldav.php/.well-known/carddav. This is certainly a mistake in server configuration.

        D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 >> "OPTIONS /caldav.php/testuser/ HTTP/1.1[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 >> "Host: calendar.testdomain.tld[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 >> "Connection: Keep-Alive[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 >> "User-Agent: DAVdroid/0.6.1[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 >> "Authorization: Basic c2FicmluYTp0ZXN0[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 >> "[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "HTTP/1.1 200 OK[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "Date: Wed, 30 Jul 2014 22:15:45 GMT[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "Content-Type: text/plain; charset="utf-8"[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "Transfer-Encoding: chunked[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "Connection: close[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "X-Powered-By: PHP/5.5.14-pl0-gentoo[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "Server: 1.1[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "Allow: OPTIONS, PROPFIND, REPORT, DELETE, LOCK, UNLOCK, MOVE, GET, HEAD, MKCOL, MKCALENDAR, PROPPATCH, BIND, ACL[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "X-DAViCal-Version: DAViCal/1.1.1; DB/1.2.11[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "0[\r][\n]"
    D/ch.boye.httpclientandroidlib.wire(24018): http-outgoing-4 << "[\r][\n]"
    W/davdroid.ServerInfoLoader(24018): Found address-book home set, but it doesn't advertise CardDAV support

    Your server advertises support for the HTTP methods OPTIONS, PROPFIND, REPORT, DELETE, LOCK, UNLOCK, MOVE, GET, HEAD, MKCOL, MKCALENDAR, PROPPATCH, BIND, ACL.
    DAVdroid uses (and since 0.6, checks for!) PROPFIND, REPORT, GET, PUT, DELETE.

    However, your server doesn’t advertise support for PUT (which is needed for sending contacts/events to the server), although it probably supports it.

    DAVdroid 0.5.14 didn’t check for PUT, but only for PROPFIND and DELETE so this is why DAVdroid 0.5.14 works for you.

    So this is a bug in DAViCal. Can you create an issue in the DAViCal bug tracker (if there is one?), or shall I do that?

    0
  • A

    That was fast, thanks a lot!

    0
  • A

    Thank you for your response. I feel that my needs as a user are not considered appropriately in this matter. Closing this issue before I even answer feels strange. I’m neither using nor recommending Davdroid for the time being. It is just too much hassle.
    Your recommendation “If you don’t know whether your server works and how its settings are, please use another non-mobile client, curl or whatever to test your server.” was taken up by me and it took me two full days to create a toolset that let me debug the situation. After I was finished with this I thought that what Davdroid does is purely ridiculous. I think quite a few users have the need to be able to check their setup. Your question: "Do you really think it’s wise to keep 20 services * 10 versions = 200 profiles of services with different paths and settings and then still just be able to cover the default settings? " is considered rude by me. The question is from the solution side and not from the problem side. On the problem side there is a single user with a single setup that needs to check whether things are working. This need shouldn’t be ignored.

    0
  • A

    @WolfgangFahl It’s natural to use a second client to test any client-server pair using any protocol. That’s one of the first steps to narrowing down the source of a problem, and it has been for decades. This makes even more sense when one of the clients is a smart phone, where it’s more of a hassle to get logs.

    As for the quick closing of the issue, if you find that your particular problem is not resolved, I don’t suppose anyone would complain if you reopen it.

    0

Similar topics