They cannot find any mistake. Syncing works on other devices, just not with davx5 on Android.
.well-known url not checked w/o SRV RR
-
Hello,
I don’t know which version of davdroid I used when I first installed it (probably 6 or more months back), but then I could add a new account with email/password since I set up the correct well-known urls for caldav and carddav.
Now I wanted to set it up on another phone, but it can’t find the resources. Not even with the same account. I even tried it on the phone it worked by deleting the account and re-adding. --> same result, so some update it davdroid caused it.
I found the problem myself by digging into the source code.
Apparently the .well-known urls don’t get checked anymore if there was no SRV record found for the domain…Was this intended? Afaik the RFC doesn’t specify this.
Please revert this regression if there is no reason against it.
Thank you!Greetings,
Philipp -
Apparently the .well-known urls don’t get checked anymore if there was no SRV record found for the domain…
Can’t believe that, as I use a server with well-known URLs, but without SRV/TXT record myself.
Can you back this up by quoting the code lines?
-
At line 202 it starts the search for the principal since with a “mailto” baseURI no principalUrl is set yet.
And if at line 390 no SRV RR was found, “/.well-known/…” won’t be added at line 412 therefore never checked by the foreach in 417.Did you have the chance to try to readd your account with your configuration? But I really think there is - at least there was - no problem before.
-
@Philipp said:
At line 202 it starts the search for the principal since with a “mailto” baseURI no principalUrl is set yet.
And if at line 390 no SRV RR was found, “/.well-known/…” won’t be added at line 412 therefore never checked by the foreach in 417.Sory, I don’t understand that. Line 412 and line 417 are dealing with TXT records. Please provide a comprehensive description of what’s wrong according to your opinion, so that I can reproduce your thoughts and see the problem. I don’t see the things you have described.
Did you have the chance to try to readd your account with your configuration? But I really think there is - at least there was - no problem before.
Yes, I have added my account again just a few days ago and it worked. We’re also constantly testing with various services (some of them with SRV records, some without, most with well-known URLs, but not all) and there are no known problems.
-
Sory, I don’t understand that. Line 412 and line 417 are dealing with TXT records.
You are right, but where is the logic then to check just for the well-known urls in combination with an account added via email/password?
Anyway. I added the appropriate SRV records, and it goes one step further, finding the correct principal as expected.
Now I have another problem, but that’s probably caused by my hoster and doesn’t belong to this thread.
http://pastebin.com/raw/0s0tftps
I guess PROPFIND wasn’t used in the past for the initial setup, or my hoster isn’t supporting it anymore.– Edit:
Ok, the other problem with PROPFIND is caused because my SRV pointed to “example.com”, but the well-known url redirected to “mail.example.com” (see log). Davdroid recognized the redirect, but in the end still used “example.com” as FQDN, even though there was a redirect to another, in this case, subdomain.
The RFC is not clear on that either, but it probably is right the way it is now. -
@Philipp said:
You are right, but where is the logic then to check just for the well-known urls in combination with an account added via email/password?
You’re right, at the moment, the domain part of the email address is not tried.
For service discovery by URL, there is
if (principalUrl == null) // still no principal URL, try service discovery with "domain" = user-given host name domain = baseURI.getHost();but this fallback is missing for discovery by email addresses. This is by intention, but maybe it would make sense to try whether the domain part is a valid host name:
RFC 6764 Client “Bootstrapping” Procedures:
If an SRV record is not found, the client will need to prompt the user to enter the FQDN and port number information directly or use some other heuristic, for example, using the extracted “domain” as the FQDN and default HTTPS or HTTP port numbers. In this situation, clients MUST first attempt an HTTP connection with TLS.
Davdroid recognized the redirect, but in the end still used “example.com” as FQDN, even though there was a redirect to another, in this case, subdomain.
Your server has returned
https://example.com/owncloud/remote.php/carddav/principals/philipp@example.com/as the principal URL. DAVdroid trusts this information and will use this principal URL. It follows redirects, but only for a single request – the principal URL will not change, as it has been queried explicitly. -
@rfc2822 said:
RFC 6764 Client “Bootstrapping” Procedures:
If an SRV record is not found, the client will need to prompt the user to enter the FQDN and port number information directly or use some other heuristic, for example, using the extracted “domain” as the FQDN and default HTTPS or HTTP port numbers. In this situation, clients MUST first attempt an HTTP connection with TLS.
But this is part of step 2. Determination of service FQDN and port number.
But we are at step 3. Determination of initial “context path”.
and there it is:When an initial “context path” has not been determined from a TXT record, the initial “context path” is taken to be “/.well-known/caldav” (for CalDAV) or “/.well-known/carddav” (for CardDAV).
Which is the situation we have: No SRV and no TXT record.
I find it overly strict to read this in a way, that a vaild SRV record is a precondition to trying to use wll-known paths.