Red Hat Bugzilla – Bug 458892
GNOME VFS and WebDAVS
Last modified: 2015-03-03 17:33:03 EST
Description of problem:
Unable to use WebDAVS under F9, it worked well under F8.
Version-Release number of selected component (if applicable):
2) Connect to Server
3) Service Type is missing WebDAVS (https)
Please restore, this is my first time using bugzilla so if I am missing any information around this issue let me know.
The workaround doesn't work in F9.
This bug is still present in Fedora 10. Aly: could you bump the version number please?
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).
Mistyped: it should read "So you can't download directories."
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.
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
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.
I'm not seeing this problem in Fedora 11 anymore.
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:
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.