Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

CalDav against Google: "Missing capabilities: Couldn't determine principal path (RFC 5397)" #122

Closed
jas4711 opened this Issue · 15 comments

8 participants

@jas4711

Hi.

I'm trying to setup DAVDroid to sync a calendar against Google.

I use https://www.google.com/calendar/dav/simon@josefsson.org/events as the root URL, and my email address simon@josefsson.org as username, and an app-specific password. However, clicking next, I get the error "Missing capabilities: Couldn't determine principal path (RFC 5397)".

Is this a problem with DAVDroid, or maybe Google doesn't implement the full protocol?

Or is my URL wrong? I got that one from Google's help on CalDav:

https://support.google.com/calendar/answer/99358

I have also tried replacing "/events" with "/user" but I get the same error.

I'm hoping this should be easy to reproduce for anyone with a Google account.

/Simon

@rfc2822
Owner

I have now tested with a Google account and got these logs:

Received HTTP/1.1 200 OK
Prepared PROPFIND request: <propfind xmlns="DAV:">
   <prop>
      <current-user-principal/>
   </prop>
</propfind>
Setting SNI hostname
Established TLSv1 connection with www.google.com using TLS_ECDHE_RSA_WITH_RC4_128_SHA
Received HTTP/1.1 207 Multi-Status
Trying to repair invalid URL: /calendar/dav/XXXXX@gmail.com/user/ -> /calendar/dav/XXXXXX%40gmail.com/user/
Processing multi-status element: https://www.google.com/calendar/dav/XXXXXXX%40gmail.com/user/
Content: <?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:caldav="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:ical="http://apple.com/ns/ical/">
 <D:response xmlns:carddav="urn:ietf:params:xml:ns:carddav">
  <D:href>/calendar/dav/XXXXXX@gmail.com/user/</D:href>
  <D:propstat>
   <D:status>HTTP/1.1 404 Not Found</D:status>
   <D:prop>
    <D:current-user-principal/>
   </D:prop>
  </D:propstat>
 </D:response>
</D:multistatus>

So, it seems that Google doesn't support RFC 5397 which would be required for auto-detecting CalDAV/CardDAV resources.

I'm closing this because Google Calendar is not supported by DAVdroid.

Just for curiousity – may I ask why you don't just use the Google Calendar app?

@rfc2822 rfc2822 closed this
@jas4711

Thanks for debugging!

I don't use the Google Calendar app because I'm running Replicant on my Samsung S3 and want as little proprietary stuff on my phone as possible. As far as I can tell, you can't use Google Calendar without also installing some non-free stuff (like GAPPS).

@rfc2822
Owner

Ok… so I suggest to use a free calendar server, too :) Or if you have to rely on Google calendar for some reasons, you will have to use GApps, too.

@jeekajoo

Hi, I personaly have to use the google calendar server because of the company I'm working for.
However I want to keep my phone 'gapps' free.
Acal is working perfectly as a google calendar client but I would prefer using davdroid. Why? because that would allow me to use the default calendar (much more nicer interface than acal). ;)

@rfc2822
Owner

@jeekajoo I understand. However at the moment it's not possible because Google lacks support for RFC 5397.

@jas4711

Reflecting on this, I wonder how aCal deals with Google Calendar? Obviously aCal works against Google. Presumably aCal doesn't need or require this particular aspect of CalDAV to work. Maybe there is a workaround in aCal to get the same functionality some other way? I'm wondering if maybe DAVDroid could be adapted to either use a similar workaround, or be adapted to work even though this particular feature is not supported by the server.

Speaking as a old IMAP implementer, I fully understand the ugliness of adding code to support broken servers (there are many broken IMAP servers around), and one should be hesitant about adding such code, but sometimes workarounds can be fairly small and not pose significant risks of breaking something else. I guess the same applies to the CalDAV protocol and implementations therof. Perhaps we can discuss possible workarounds in this bug report.

I suggest the next step (for anyone interested) to move forward on this is to 1) figure out how aCal works around this, and/or 2) debug how the Google CalDAV server work and try to come up with a workaround. Until there is more knowledge here, I don't think we can write a patch, and without a patch I don't think we'll see any progress here.

/Simon

@rfc2822
Owner

Reflecting on this, I wonder how aCal deals with Google Calendar? Obviously aCal works against Google. Presumably aCal doesn't need or require this particular aspect of CalDAV to work. Maybe there is a workaround in aCal to get the same functionality some other way? I'm wondering if maybe DAVDroid could be adapted to either use a similar workaround, or be adapted to work even though this particular feature is not supported by the server.

Current Principal isn't even a part of CalDAV but an additional extension that allows auto-detection of CalDAV/CardDAV collections. So Google isn't required to support this in any way to be standards-compliant. However, we have decided to require auto-detection as most servers support it and without it, the setup process would be much more complicated and error-prone.

Speaking as a old IMAP implementer, I fully understand the ugliness of adding code to support broken servers (there are many broken IMAP servers around), and one should be hesitant about adding such code, but sometimes workarounds can be fairly small and not pose significant risks of breaking something else. I guess the same applies to the CalDAV protocol and implementations therof. Perhaps we can discuss possible workarounds in this bug report.

Two things:

  1. We have founded DAVdroid as a way to escape Google (meaning Google address book and Google Calendar) and still use our Android devices. This was our personal motivation, so we don't like to support Google Calendar in any way. If it would work like any other CalDAV/CardDAV service, there wouldn't be any reason to not use it with DAVdroid, but I won't do any work just to support Google services (which I want to get rid of). I understand that Google support might by useful for some users, but my disfavor is a personal thing. Pull requests are, however, appreciated.
  2. We don't do server-specific workarounds: We give our best to improve the standards-compliance of DAVdroid. If we discover that some server/service is not compliant, we will report these problems to the manufacturer and help them to make it compliant. So servers and clients are improved. (Note: We just discovered a service that had a User-Agent based decision algorithm that served corrupted data only to DAVdroid because they had implemented a work-around for a DAVdroid bug that has been fixed long ago.) Again, this might not be the short-time optimum for users, but over a long time they will benefit from improved servers and clients, making the whole CalDAV/CardDAV experience smoother. I'm happy that we don't have an economic dependency of DAVdroid, so we can afford to push our own way.

I suggest the next step (for anyone interested) to move forward on this is to 1) figure out how aCal works around this, and/or 2) debug how the Google CalDAV server work and try to come up with a workaround. Until there is more knowledge here, I don't think we can write a patch, and without a patch I don't think we'll see any progress here.

As said above, I'm not actively interested in working Google support. However, if someone can contribute a good and standards-compliant solution that allows DAVdroid to be used with Google, we'd of course merge the changes.

@Aeyoun

Can this please be reopened?

I do not want to use Google Calendar directly because that requires me to add the Google Account from my employer to my device. That requires me to accept my employer as a remote device administrator. I am frankly not interested in that and wanted to use this app as a work-around.

@biophysics

@rfc2822 Could you please write in your http://davdroid.bitfire.at/what-is-davdroid that your app does not sync google calendar. Will save time for others. Thanks.

@ahmet2mir

If you wan't to use native Android account management instead of aCal, use https://f-droid.org/repository/browse/?fdid=org.gege.caldavsyncadapter, work great with my entreprise account https://github.com/gggard/AndroidCaldavSyncAdapater/wiki/Server-Compatibility-List with the version 1.8 not the 1.8.1

@freechelmi

Whoo , just read the comments on this bug and I'm a bit surprised.
If google did not support the required bits of DAV protocol, I would understand but you are saying something like " we don't want to put some manual way of feeding the DAV urls to the apps because autodiscovery is great and we hate google".

I understand it's a lot of work, but it would make common people able to use android without gapps.

@rfc2822 rfc2822 reopened this
@rfc2822
Owner

" we don't want to put some manual way of feeding the DAV urls to the apps because autodiscovery is great"

Correct.

"and we hate google".

Speaking for me personally, correct (although my opinion is a bit more differentiated). But that's not the point in this issue. The point is that I

  • don't want to do work just to get Google Calendar running
  • while there is already a working (and better working!) Google Calendar app, namely Google Calendar. If you really need Google, well then install GApps. Why not?

But of course, if someone submits a high-quality pull request that has a well-done UI that doesn't interfere with auto-detection and doesn't cause any other problems, I'll be happy to merge it. We won't lock out Google Calendar specifically for any reason, but we won't do any extra work just to get it working, too, especially because there's a working Google Calendar app.

@dper

@freechelmi I think you got the order of things mixed up. It is Google that cares little about extensive CalDAV support. Otherwise, Google would have implemented auto-detection already, or at least they'd have plans to do so in the near future. After all, there are plenty of talented and funded software developers working there. It only makes sense that Google should be working to make its own products more accessible to third party developers and end users, not the other way around. After all, they're the company making money here. (Although because they have their own functional calender application -- regrettably part of a bundle that many of us find distasteful -- it's unlikely their priorities will shift.)

@freechelmi

@dper Totally agree with you as well, I think Card/Caldav is also important to google, as it's the official way for iOs and windowsphone to sync AFAIK.

@rfc2822 rfc2822 added duplicate and removed question invalid labels
@rfc2822
Owner

Please follow up in #234.

@rfc2822 rfc2822 closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.