GNOME Bugzilla – Bug 585175
Error in parsing response to authenticated PROPFIND request
Last modified: 2009-10-09 17:17:22 UTC
Please describe the problem: The DAV backend has a problem parsing the multistatus response of a PROPFIND request under the following conditions: * The server requires digest authentication, AND * the server replies with a complete URI (i.e. http://server/path) in the D:href part of the multistatus response to a PROPFIND request, AND * gvfs is provided with the user name as part of the URI (i.e. http://user@server/path). Under this condition the function ms_response_is_target cannot match the URI of the target resource with the URI specified in the multistatus response because the latter is missing the user name in its URI. Note that if the server replies just with a path in D:href (i.e. /path), like it is the case with Apache 2, then the username and password are copied over by soup_uri_new_with_base and the following comparison works. Steps to reproduce: 1. Set up a DAV server which fulfills the above requirement, eg. lighttpd. 2. Try to mount the resource, eg. gvfs-mount dav://user@server/path/ Actual results: The user is asked to enter the password and then the mount command fails: Enter password for <realm> Password: **** Error mounting location: HTTP-Error: Authorization Required Expected results: gvfs-mount should succeed. Does this happen every time? Happens every time. Other information: With the mound command the error can be circumvented by not specifying the user name on the command line but entering it interactively, so it is not part of the URI. However when trying to publish an Evolution calendar to a DAV share the user name is put into the URI by the program itself, so there is no way around fixing this. A patch follows in my next comment.
Created attachment 136154 [details] [review] Fix against today's head This fix is pretty much identical to how the redirection bug was fixed, see http://bugzilla.gnome.org/show_bug.cgi?id=529349
*** This bug has been marked as a duplicate of bug 529349 ***
Very good analysis, btw. ;-) [Sorry for the spam]
Christian, as this bug just needs the same type of fix as bug 529349 but is not 100% identical, is it indeed fixed now? -Thomas