Bug 458892 - GNOME VFS and WebDAVS
Product: Fedora
Classification: Fedora
Component: gnome-vfs2 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-08-12 19:17 EDT by Aly Dharshi
Modified: 2015-03-03 17:33 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 01:18:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Aly Dharshi 2008-08-12 19:17:48 EDT
Description of problem:
Unable to use WebDAVS under F9, it worked well under F8.

Version-Release number of selected component (if applicable):

How reproducible:
1) Places
2) Connect to Server
3) Service Type is missing WebDAVS (https)

Additional info:

Please restore, this is my first time using bugzilla so if I am missing any information around this issue let me know.

See: http://fedoraforum.org/forum/showthread.php?t=194022

The workaround doesn't work in F9.
Comment 1 Armijn Hemel 2008-12-15 08:48:33 EST
This bug is still present in Fedora 10. Aly: could you bump the version number please?
Comment 2 Robert Evans 2009-01-09 12:07:26 EST
There are two ways you can connect to a webdavs server from nautilus.
One is to Connect to Server with Service Type "Custom Location". Use
as the Location URI.

The other is to create a file /usr/share/gvfs/mounts/davs.mount containing

The file is missing from gvfs-0.2.5-1.fc9.

This will make the Service Type "Secure WebDAV (HTTPS)" appear in the pull-down menu.

However, I've experienced problems in connecting using the "Secure WebDAV (HTTPS)" service type. With "Custom Location" you give your username and password when prompted, but with "Secure WebDAV (HTTPS)" you give them in the Connect to Server panel. The first worked, but not the second. (Leaving the fields blank so that you get a separate prompt for the username and password works).

Also, there is a more serious problem. Once connected, if you drag a remote directory from the WebDAV server to your local space, then Nautilus creates a file containing the HTML listing of the directory and not the directory and its contents themselves. So you can downlad directories.

The bug has prevented me from using Fedora 9 for my student lab.

The bug is, probably, in gvfs or in libsoup-2.4.1-1.fc9 (which it uses to do WebDAV).
Comment 3 Robert Evans 2009-01-09 12:09:27 EST
Mistyped: it should read "So you can't download directories."
Comment 4 Tim Niemueller 2009-02-14 07:45:12 EST
I have just tried to mount a WebDAV directory via HTTPS (provided by an Apache with mod_dav and mod_ssl). It seems to connect fine (with user credentials), but then fails to open the directory in Nautilus. When I look in the Apache log there a first a few PROPFIND requests for the proper path (like /dav). Then once you try to open it in Nautilus you get in the log something like:

"OPTIONS / HTTP/1.1" 302 - "-" "gvfs/1.0.3"

So it seems that it mixes up the path. The error message it shows is "HTTP error: found", which is probably short for the 302 "HTTP_FOUND" status code.

Since this used to be one of the easiest and safest way to share files with others I really hope that this can be fixed soon.
Comment 5 Michael H. Warfield 2009-04-16 16:15:10 EDT
I'm also experiencing this (although I thought I had this working under F9.  Maybe it was F8).  I found that the "Custom" connection with davs://server/path seems to be ignoring the path and it attempts to get OPTIONS on / and then reports DAV is not enabled.

I also had to add these lines to the server.  I think this is what got the F9 connection to work properly (the first line).  F10 is reporting the user agent in the second line and that changed the behavior but it still didn't solve the lost path problem.

BrowserMatch "^gvfs/0.2.5" redirect-carefully
BrowserMatch "^gvfs/1.0.3" redirect-carefully
Comment 6 Michael H. Warfield 2009-04-16 16:52:46 EDT
Just tried the trick of creating the file /usr/share/gvfs/mounts/davs.mount.  Ok, that was nice.  That returned the entry for type "Secure Webdav (https)" in the connect to server menu.  Too bad it didn't work.  It gave the same results as using a custom davs://server/path.  It complains that it's not a webdav enabled share but it's querying / on the server for options.

Just as a double check, I also commented out the "Broswer Match" lines I have above and then it complains "http: permanently moved".  Put them back into the server and then it tries again but the path is wrong.
Comment 7 Armijn Hemel 2009-08-06 16:07:29 EDT
I'm not seeing this problem in Fedora 11 anymore.
Comment 8 Bug Zapper 2009-11-18 03:15:47 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 9 Bug Zapper 2009-12-18 01:18:10 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.