GNOME Bugzilla – Bug 694734
Relative URI in Location on PUT confuses WebDAV
Last modified: 2013-02-28 18:09:52 UTC
Deleting a contact via the WebDAV backend causes the evolution-addressbook-factory component to die with a segmentation fault. I'm running the evolution-addressbook-factory as: WEBDAV_DEBUG=all /usr/lib/evolution-data-server/evolution-addressbook-factory --keep-running --wait-for-client After I see a successful Multistatus response which retrieves the getetag value of each contact, I attempt to delete a contact and the evolution-addressbook-factory dies with a Segmentation Fault. (gdb) bt
+ Trace 231572
No DELETE (or any) request appears to be made to the server relating to the DELETE operation, the fault appears to occur prior to any HTTP operation is attempted.
evolution-3.6.3-1.1.x86_64 openSUSE 12.2 w/GNOME 3.6 from dimstar's repo Linux workstation.wmmi.net 3.4.28-2.20-desktop #1 SMP PREEMPT Tue Jan 29 16:51:37 UTC 2013 (143156b) x86_64 x86_64 x86_64 GNU/Linux glib-networking-2.34.2-1.3.x86_64 glibc-2.15-22.17.1.x86_64 libglib-2_0-0-2.34.3-3.1.x86_64
Deleteting a contact in another WebDAV address book fails with: "(evolution-addressbook-factory:10545): libebookbackendwebdav-WARNING **: DELETE failed with HTTP status 2 Which is posted via a message dialog in the Evolution UI. But no DELETE call appears to be made. (and 2 is obviously not a valid HTTP response).
Thanks for a bug report. The 2 is SOUP_STATUS_CANT_RESOLVE. The lines in question look like this: > 407 guint status; > 408 > 409 message = soup_message_new (SOUP_METHOD_DELETE, uri); > 410 soup_message_headers_append (message->request_headers, "User-Agent", USERAGENT); > 411 soup_message_headers_append (message->request_headers, "Connection", "close"); I see from the backtrace that the 'uri' is a relative path, not an absolute URI, as is supposed, thus the soup_message_new() returns NULL, and then next like the NULL is dereferenced. Checking the code further it shows that the WebDAV backend relies on the contact's UID being a full URI for it. I cannot guess from the code how you got to a state with invalid UID being set on a contact, though from the SOUP_STATUS_CANT_RESOLVE I'd say your WebDAV URI is garbled in the configuration, try to check it, please.
> I see from the backtrace that the 'uri' is a relative path, not an absolute > URI, as is supposed, thus the soup_message_new() returns NULL, and then next > like the NULL is dereferenced. > Checking the code further it shows that the WebDAV backend relies on the > contact's UID being a full URI for it. "contact's UID being a full URI for it." Is that really legal for the WebDAV/CardDAV spec? I have vCards where the UID is not the URI/HREF, and those seem to work fine. I guess I should try to update those. That seems like an odd requirement. > I cannot guess from the code how you got > to a state with invalid UID being set on a contact, I think I know. The PUT for a new contact to the server has a Location: header in the response that indicates the authoritative location of the new object (201 response). If I create a Contact in Evo I then can't update it, it just creates a duplicate [locally] and trying to do any further updates causes this crash. I have worked around by adjusting the user-agent definition for Evolution on the server telling it that Evolution doesn't support Location: headers. It appears I can now create and update contacts. So... I guess we can close this one since it can be worked around. UID handling seems dorked to me though.
The UID can be anything, the only constraint is that it should be unique in the book. I do not know why the writer used UID for storing this information, maybe it had a meaning for him. In any case, I suppose the server used a relative URI in the Location header, which confused the backend. This can be fixed on evolution-data-server's side, which will be better than fixing it on each server. The only thing is that my server works fine, thus I'll not be able to test this properly. Will you be able to test an eds change for me, please?
Created attachment 237638 [details] [review] eds patch for evolution-data-server; Found it (by cheating in a code during testing). The reason is that webdav backend instructed to construct only path, even the code was there to make full paths from relative paths. I added a bit more checking there too, just in case, otherwise it would be just a TRUE->FALSE one-liner.
Created commit 2186c91 in eds master (3.7.91+) Created commit f1a6b21 in eds gnome-3-6 (3.6.4+)