GNOME Bugzilla – Bug 679051
WebDAV MOVE requests contain username in Destination header
Last modified: 2018-09-21 17:15:44 UTC
soup_uri_to_string encodes authentication information in the returned string. When passed in the Destination: header of MOVE requests (presumably also COPY, although I don't think gvfs sends these) this confuses some servers. This bug is particularly bad from a usability POV as nautilus is only able to create folders called "Untitled Folder" since the subsequent MOVE request fails. The attached patch requests a relative URI instead, which should suffice as AFAIK gvfs never sends cross-domain MOVEs. Some network traces: BEFORE: MOVE /Untitled%20Folder HTTP/1.1 Host: davtest Destination: http://Administrator@davtest/g Overwrite: F Accept-Encoding: gzip, deflate User-Agent: gvfs/1.13.2 Accept-Language: en-gb, en;q=0.9, en;q=0.8 Connection: Keep-Alive Authorization: Basic QWRtaW5pc3RyYXRvcjpmb28= HTTP/1.1 400 Bad Request Content-Type: text/html Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Mon, 25 Jun 2012 10:00:40 GMT Content-Length: 11 Bad Request AFTER: MOVE /Untitled%20Folder HTTP/1.1 Host: davtest Destination: /j Overwrite: F Accept-Encoding: gzip, deflate User-Agent: gvfs/1.13.2 Accept-Language: en-gb, en;q=0.9, en;q=0.8 Connection: Keep-Alive Authorization: Basic QWRtaW5pc3RyYXRvcjpmb28= HTTP/1.1 201 Created Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Thu, 28 Jun 2012 10:47:32 GMT Content-Length: 0
Created attachment 217505 [details] [review] use relative URIs in Destination header
Review of attachment 217505 [details] [review]: While the patch looks good and does what it says it should, unfortunately this breaks things for me for an Apache webdav server: Before: > MOVE /dav/f3 HTTP/1.1 > Soup-Debug-Timestamp: 1384234218 > Soup-Debug: SoupSessionSync 1 (0xbe1100), SoupMessage 3 (0x7f9404005280), SoupSocket 2 (0x7f940400a980) > Host: localhost:8080 > Destination: http://ross@localhost:8080/dav/f1 > Overwrite: F > Accept-Encoding: gzip, deflate > User-Agent: gvfs/1.19.2 > Accept-Language: en-za, en;q=0.9, en-us;q=0.8, en;q=0.7, en;q=0.6 > Connection: Keep-Alive < HTTP/1.1 201 Created < Soup-Debug-Timestamp: 1384234218 < Soup-Debug: SoupMessage 3 (0x7f9404005280) < Date: Tue, 12 Nov 2013 05:30:18 GMT < Server: Apache/2.4.4 (Mageia) < Location: http://localhost:8080/dav/f1 < Content-Length: 71 < Keep-Alive: timeout=5, max=100 < Connection: Keep-Alive < Content-Type: text/html; charset=ISO-8859-1 < < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> < <html><head> < <title> With your patch: > MOVE /dav/f3 HTTP/1.1 > Soup-Debug-Timestamp: 1384234061 > Soup-Debug: SoupSessionSync 1 (0xa26100), SoupMessage 3 (0x7f31d8005650), SoupSocket 2 (0x7f31d800a8d0) > Host: localhost:8080 > Destination: /dav/f1 > Overwrite: F > Accept-Encoding: gzip, deflate > User-Agent: gvfs/1.19.2 > Accept-Language: en-za, en;q=0.9, en-us;q=0.8, en;q=0.7, en;q=0.6 > Connection: Keep-Alive < HTTP/1.1 400 Bad Request < Soup-Debug-Timestamp: 1384234061 < Soup-Debug: SoupMessage 3 (0x7f31d8005650) < Date: Tue, 12 Nov 2013 05:27:41 GMT < Server: Apache/2.4.4 (Mageia) < Content-Length: 226 < Connection: close < Content-Type: text/html; charset=iso-8859-1 < < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> < <html><head> < <title>400 Bad Request</title> < </head><body> < <h1>Bad Request</h1> < <p>Your browser sent a request that this server could not understand.<br /> < </p> < </body></html>
Created attachment 259633 [details] [review] dav: Don't send auth information in the Destination header Because some servers get confused by URIs with auth information in the destination header and some server get confused by path absolute references, send absolute URIs without the auth information.
@Tom, please test the patch and see if it works for your webdav server.
Thanks for looking into this, and apologies for my slow response: I needed to install a new server locally as I no longer have access to the one I was using previously. I can confirm that Apache (2.2.22-6ubuntu5.1) returns 400 for relative Destinations. This puzzles me as I'm almost certain I tested my patch on Apache before filing this bug. However, since I last looked at this problem gvfs's behaviour seems to have changed. Here is a log from a stock Ubuntu installation (gvfs-backends 1.18.2-0ubuntu1, libsoup 2.42.2-6), which shows the behaviour of your proposed patch already in place: MOVE /Untitled%20Folder HTTP/1.1 Host: 192.168.122.228 Destination: http://192.168.122.228/h Overwrite: F Accept-Encoding: gzip, deflate User-Agent: gvfs/1.18.2 Accept-Language: en-gb, en;q=0.9, en;q=0.8 Connection: Keep-Alive Authorization: Basic QWRtaW5pc3RyYXRvcjpBYTEh HTTP/1.1 201 Created Server: Microsoft-IIS/7.5 Date: Wed, 20 Nov 2013 20:26:19 GMT Content-Length: 0 Obviously this runs counter to the log you posted above, which shows clearly the incorrect behaviour that I reported initially. So I am now quite confused. I will retry with git HEAD and report back.
Yeah, that does seem odd. Please try with gvfs and libsoup from git.
Are you sure about the Ubuntu 13.10 behavior? I just tried it with gvfs 1.18.2 and libsoup 2.42.2-6: gvfs-mount dav://ross@localhost/dav gvfs-rename dav://ross@localhost/dav/cat dog The result is: MOVE /dav/cat HTTP/1.1 Host: localhost Destination: http://ross@localhost/dav/dog Overwrite: F Accept-Encoding: gzip, deflate User-Agent: gvfs/1.18.2 Accept-Language: en-us, en;q=0.9 Connection: Keep-Alive Authorization: Basic cm9zczp0ZXN0 HTTP/1.1 201 Created Date: Sat, 30 Nov 2013 19:38:41 GMT Server: Apache/2.4.6 (Ubuntu) Location: http://localhost/dav/dog Content-Length: 71 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1 So the username *is* placed in the Destination header with gvfs 1.18.2 and an Apache server.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/186.