While not strictly necessary for a pure CardDAV client, this change
allows a plain DAV client to start from the principal path and discover
the home set and within it the addressbook objects.
Example cadaver session:
conrad@serotonin ~/go/src/github.com/emersion/go-webdav $ cadaver http://localhost:8080/Y29ucmFk/
Authentication required for Please provide your IMAP credentials on server `localhost':
Username: conrad
Password:
dav:/Y29ucmFk/> ls
Listing collection `/Y29ucmFk/': succeeded.
Coll: contacts 0 Jan 1 1970
dav:/Y29ucmFk/> cd contacts
dav:/Y29ucmFk/contacts/> ls
Listing collection `/Y29ucmFk/contacts/': succeeded.
1ddb4906edda8d7b63caf30414f3f9491c065b46.vcf 225 May 3 16:15
8440297a76458ead82593d7bb85eb26861a31c27.vcf 212 May 3 16:22
cfbaf6f7a40a58cc9dd54c6a112d9c4edd3c96e3.vcf 216 May 3 16:16
dav:/Y29ucmFk/contacts/>
This did not work before.
While most clients work fine without this, I understand this to be a requirement for this setup to be valid WebDAV (highlighting mine):
For all WebDAV-compliant resources A and B, identified by URLs "U" and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain exactly one mapping from "blah" to B.
Note: This PR is actually mostly to highlight an issue I noticed. Both with and without this change, the code was actually no longer compatible with the old "both user principal URL and home set URL are /" approach (I broke it, sorry), because if the two are equal the properties for the latter will never be returned.
I initially looked into supporting that, but doing so really complicates things. Imagine this change while keeping that approach working. The code would have to handle:
Path is principal URL -> add principal properties
Path is also home set URL because they are equal -> add home set properties to same response
Path is principal URL, not home set URL, depth is > 0 -> add home set properties as new response
Path is principal URL and home set URL, depth is >0 -> add address objects as new responses
Path is principal URL, not home set URL, depth is >1 -> add address objects as new responses
This would however make the assumption that the home set URL is actually under the principal URL, which I suppose doesn't even have to be the case.
So what to do? I think the questions are:
Do we care about this being plain WebDAV compatible? We could say we don't, and if an implementation needs that, it should handle requests to anything below the home-set path itself?
Do we want the "multiple things at the same path" approach to keep working? If so, I think it would require some refactoring of the propfind*() functions so they can add properties to the same response.
Also, maybe you have some other thoughts or ideas? :slightly_smiling_face:
While not strictly necessary for a pure CardDAV client, this change allows a plain DAV client to start from the principal path and discover the home set and within it the addressbook objects.
Example cadaver session:
This did not work before.
While most clients work fine without this, I understand this to be a requirement for this setup to be valid WebDAV (highlighting mine):
Note: This PR is actually mostly to highlight an issue I noticed. Both with and without this change, the code was actually no longer compatible with the old "both user principal URL and home set URL are
/
" approach (I broke it, sorry), because if the two are equal the properties for the latter will never be returned.I initially looked into supporting that, but doing so really complicates things. Imagine this change while keeping that approach working. The code would have to handle:
This would however make the assumption that the home set URL is actually under the principal URL, which I suppose doesn't even have to be the case.
So what to do? I think the questions are:
propfind*()
functions so they can add properties to the same response.Also, maybe you have some other thoughts or ideas? :slightly_smiling_face: