GNOME Bugzilla – Bug 565495
Wrong HTTP command for Webdav with GVFS
Last modified: 2014-07-04 17:13:22 UTC
From Launchpad: "I have Webdav enabled in Apache2. In Nautilus I can see the root directory of the webspace. But if I want to move to a directory I get an error 301 "Permanently Moved". Move to directory /Backup: 84.134.20.250 - tomi [23/Dec/2008:18:35:48 +0100] "PROPFIND /Backup HTTP/1.1" 301 388 "-" "gvfs/1.0.2" It works with Konqueror: 84.134.20.250 - tomi [23/Dec/2008:18:49:36 +0100] "PROPFIND /Backup/ HTTP/1.1" 207 3012 "-" "Mozilla/5.0 (compatible; Konqueror/4.1; Linux) KHTML/4.1.3 (like Gecko)" Nautilus does not add the slash as it should do." Corresponding Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/310967
Exactly the same for me, error box saying "Moved permanently" when trying to open a directory since upgrading to gvfs 1.0.2 (SuSE 11.1). File access on the top level works fine. Konqueror works, Nautilus fails. Just observed a slightly different behavior on the access_log: When trying to open a directory, *TWO* PROPFINDs occur: 87.123.247.209 - balzer [01/Jan/2009:12:24:02 +0100] "PROPFIND /900_Archiv/ HTTP/1.1" 207 9118 "-" "gvfs/1.0.2" 87.123.247.209 - balzer [01/Jan/2009:12:24:02 +0100] "PROPFIND /900_Archiv HTTP/1.1" 301 327 "-" "gvfs/1.0.2" The first seems to have the trailing slash and also seems to deliver correct data (status 207), only the second fails. (Why the second PROPFIND?) When trying to list (ls -l) the ~/.gfvs/... directory, i get this: ls: cannot access 900_Archiv: Input/output error ... ?????????? ? ? ? ? ? 900_Archiv -rwx------ 1 balzer users 7 Jan 1 11:52 hurz.txt* The mode display is the same for all directories. I thought I could make apache add the trailing slash internally by using mod_rewrite, using something like RewriteEngine on RewriteBase / RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^(.+[^/])$ $1/ [P] but every attempt so far failed, external redirects (temp/perm) just result in the same error box (other text for temp) and proxy/passthrough has no effect.
!!! SOLUTION / FIX !!! Using Apache2, you probably have a file /etc/apache2/server-tuning.conf ...containing the MPM tuning parameters AND at the end a block of BrowserMatch directives. My factory file contained: # # The following directive disables redirects on non-GET requests for # a directory that does not include the trailing slash. This fixes a # problem with Microsoft WebFolders which does not appropriately handle # redirects for folders with DAV methods. # Same deal with Apple's DAV filesystem and Gnome VFS support for DAV. # BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully BrowserMatch "^WebDrive" redirect-carefully BrowserMatch "^WebDAVFS/1.[012]" redirect-carefully BrowserMatch "^gnome-vfs" redirect-carefully So I got curious if, just perhaps, the user agent of the gnome-vfs might have changed... and indeed, it's now "gvfs/<version>" instead. So I added BrowserMatch "^gvfs" redirect-carefully and -- behold -- it works again! :-)
Are you using a username and password on the share? If so, this is probably a duplicate of bug 529349
The share is protected by digest authentication but I do not use username URIs. Also, my gvfs is version gvfs-1.0.2-2.19 -- that would contain your fix for 0.2.3, wouldn't it?
(In reply to comment #4) > The share is protected by digest authentication but I do not use username URIs. The username in the URI is the same regarding bug 529349. > Also, my gvfs is version gvfs-1.0.2-2.19 -- that would contain your fix for > 0.2.3, wouldn't it? No, its unfortunately not merged yet for some reason (will probe mailing list soon, so this can be fixed in next release).
*** Bug 582121 has been marked as a duplicate of this bug. ***
The webdav backend now correctly adds slashes for URLs that are expected to be directories. Regardless of this, it also now correctly handles 301 responses for PROPFIND requests. E.g: ::1 - - [04/Jul/2014:18:09:09 +0100] "PROPFIND /dav/moo HTTP/1.1" 301 238 ::1 - - [04/Jul/2014:18:09:09 +0100] "PROPFIND /dav/moo/ HTTP/1.1" 207 1374