GNOME Bugzilla – Bug 617171
WebDAV Addressbook backend shouldn't attempt to GET collections
Last modified: 2018-12-12 14:22:08 UTC
Evolution performs a PROPFIND on the specified collection but only requests getetag. Then it attempts to perform a GET on every HREF in the response. This invariably includes the collection URL itself (which fails) and potentially URLs for subordinate collections. If the PROPFIND also includes isCollection the backend would be able to skip performing a GET on collection URLs. curl -H 'Depth: 1' -d '<?xml version="1.0" encoding="utf-8"?><propfind xmlns="DAV:"><prop><iscollection/><getetag/></prop></propfind>' -X PROPFIND -u adam:fred123 http://localhost:8080/dav/Contacts/ <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:D="DAV:"> <D:response><D:href>/dav/Contacts</D:href> <D:propstat> <D:status>HTTP/1.1 200 OK</D:status> <D:prop><D:iscollection>1</D:iscollection></D:prop> </D:propstat> <D:propstat> <D:status>HTTP/1.1 404 Not found</D:status> <D:prop><D:getetag/></D:prop></D:propstat> </D:response> <D:response><D:href>/dav/Contacts/5940650.vcf</D:href> <D:propstat> <D:status>HTTP/1.1 200 OK</D:status> <D:prop><D:iscollection>0</D:iscollection></D:prop> <D:prop><D:getetag>5940650:28</D:getetag></D:prop> </D:propstat> </D:response> ...
Thanks for a bug report. This had partially addressed meanwhile, I guess your server behavior as well, like returning a dash at the end of the collection href, because it's what other servers do. I do not say all of them, I've just some where this works that way. The CardDAV backend skips every href when it ends with a slash or when it matches path of the URL of the collection on which the PROPFIND had been executed. It only doesn't cover every case, thus your DAV:iscollection suggesting is still applicable (I think of a case where the server contains a calendar collection, which has other non-calendar collection and the server doesn't return that subcollection href with an ending dash).
Hmm, I do not see any DAV:iscollection mention in: https://tools.ietf.org/html/rfc4918 Calendar collections also should not contain other calendar sub-collections, according to: https://tools.ietf.org/html/rfc4791#section-4.2 and similarly with CardDAV: https://tools.ietf.org/html/rfc6352#section-5.2 though they can contain generic collections, even I believe it's uncommon. The correct way might be to use DAV:resourcetype, but then the response can be significantly larger, which doesn't worth it, from my point of view. If the server returns collections with an ending dash (which it should, I believe), then the eds code is safe without increasing bandwidth usage. Thus I'm closing this in favor of the recent code (which is there since 3.26).