I never knew HTTP was supposed to accept full URLs. Thank you for the cite.
I’ve tried poking my server manually.
With PROPFIND:
$ openssl s_client -quiet -connect my.owndrive.com:443
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = EssentialSSL Wildcard, CN = *.owndrive.com
verify return:1
PROPFIND https://my.owndrive.com/remote.php/carddav/addressbooks/kousu/contacts/ HTTP/1.1
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxx=
Host: my.owndrive.com
Connection: close
HTTP/1.1 207 Multi-Status
Date: Sat, 31 Oct 2015 00:49:31 GMT
Content-Type: application/xml; charset=utf-8
Transfer-Encoding: chunked
Connection: close
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src *; font-src 'self' data:; media-src *; connect-src *
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: Sameorigin
X-Robots-Tag: none
Set-Cookie: PHPSESSIDI=xxxxxxxxxxxxxxxxxxxxxxx; path=/; secure; HttpOnly
X-Sabre-Version: 2.1.6
Vary: Brief,Prefer
DAV: 1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search
Server: Apache
3544
<?xml version="1.0" encoding="utf-8"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:card="urn:ietf:params:xml:ns:carddav"><d:response><d:href>/remote.php/carddav/addressbooks/kousu/contacts/</d:href><d:propstat><d:prop><d:getlastmodified>Fri, 30 Oct 2015 04:50:02 GMT</d:getlastmodified><d:resourcetype><d:collection/><card:addressbook/></d:resourcetype></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response><d:response><d:href>/remote.php/carddav/addressbooks/kousu/contacts/a4b48ac12e.vcf</d:href><d:propstat><d:prop><d:getlastmodified>Mon, 19 Jan 2015 03:59:09 GMT</d:getlastmodified><d:getcontentlength>371</d:getcontentlength><d:resourcetype/><d:getetag>"43a9f3f8c2e23a1f1e19e3be6bc0436f"</d:getetag><d:getcontenttype>text/vcard; charset=utf-8</d:getcontenttype></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response><d:response><d:href>/remote.php/carddav/addressbooks/kousu/contacts/1079352a-7a63-4622-86ac-7e5409ff18c9.vcf</d:href><d:propstat><d:prop><d:getlastmodified>Wed, 01 Jul 2015 21:46:21 GMT</d:getlastmodified><d:getcontentlength>4403</d:getcontentlength><d:resourcetype/><d:getetag>"5b31341c4e897667efb5d11709de7e1d"</d:getetag><d:getcontenttype>text/vcard; charset=utf-8</d:getcontenttype></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response><d:response><d:href>/remote.php/carddav/addressbooks/kousu/contacts/https%253A%252F%252Fkousu%2540my.owndrive.com%252Fremote.php%252Fcarddav%252Faddressbooks%252Fkousu%252Fcontacts%252F3e977fee-f0fa-4a95-8779-14249c3b2862.vcf.vcf</d:href><d:propstat><d:prop><d:getlastmodified>Sat, 11 Jan 2014 00:06:15 GMT</d:getlastmodified><d:getcontentlength>733</d:getcontentlength><d:resourcetype/><d:getetag>"6b8c57e884192c360441c6c64e622b0c"</d:getetag><d:getcontenttype>text/vcard; charset=utf-8</d:getcontenttype></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response><d:response><d:href>/remote.php/carddav/addressbooks/kousu
[.....]
The REPORT addressbook-query spec confuses me: I think it’s saying that not specifying a filter nor a set of properties should be the same as not filtering (i.e. do the same as unparameterized PROPFIND) and that the return format is the same as PROPFIND. Either way, since ownCloud is on SabreDAV, I should be able to trust its own docs, you’d think, and they agree with my interpretation. But if I use the exact example XML query they show I get the same “Card not found” error as DAVDroid causes.
$ openssl s_client -quiet -connect my.owndrive.com:443
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = EssentialSSL Wildcard, CN = *.owndrive.com
verify return:1
REPORT https://my.owndrive.com/remote.php/carddav/addressbooks/kousu/contacts/ HTTP/1.1
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxx=
Host: my.owndrive.com
Connection: close
Depth: 1
Content-Type: application/xml; charset=utf-8
Content-Length: 190
<card:addressbook-query xmlns:d="DAV:" xmlns:card="urn:ietf:params:xml:ns:carddav">
<d:prop>
<d:getetag />
<card:address-data />
</d:prop>
</card:addressbook-query>
HTTP/1.1 404 Not Found
Date: Sat, 31 Oct 2015 00:47:27 GMT
Content-Type: application/xml; charset=utf-8
Transfer-Encoding: chunked
Connection: close
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src *; font-src 'self' data:; media-src *; connect-src *
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: Sameorigin
X-Robots-Tag: none
Set-Cookie: PHPSESSIDI=xxxxxxxxxxxxxxxxxxxxxxx; path=/; secure; HttpOnly
X-Sabre-Version: 2.1.6
Server: Apache
ff
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:sabredav-version>2.1.6</s:sabredav-version>
<s:exception>Sabre\DAV\Exception\NotFound</s:exception>
<s:message>Card not found</s:message>
</d:error>
0
That error is somehow being triggered via at least 4 layers of indirection that I can’t follow here. I wish I could get the server to just tell me that $name it’s being called on. I don’t care about which $name it chooses, I care about all the $names.
So, I agree that this is on ownCloud’s end. You are following the spec and they, somehow, probably unintentionally, are not. However, you’ve already been making exceptions to deal with the transition:
- “Contacts sync: if REPORT addressbook-query doesn’t work, don’t ignore other exceptions than HTTP 40x errors”
- “Address book sync.: fall back to PROPFIND when REPORT addressbook-query returns 400, 403, 500 or 501 (for instance, for old OwnCloud versions)”
So, as a compatibility measure, would you add 404 to the list of fallback cases? If PROPFIND also 404s then you know the thing is really gone. I will bother the ownCloud people to see if they have a clue in the meantime.
What a painful protocol; there shouldn’t be two ways to get the exact same bytes.
I really really appreciate DAVDroid; I was using proprietary implementations before, and before that exporting to my SDcard whenever I remembered (which ended badly multiple times), and before that Google. DAVDroid is the thing that lets me rely on my phone to behave sensibly in the cloud era.