GNOME Bugzilla – Bug 153054
Problems accessing davs://mediacenter.gmx.net (webdav)
Last modified: 2008-09-06 19:07:49 UTC
Distribution: Debian 3.1 Package: nautilus Severity: normal Version: GNOME2.8.0 unspecified Gnome-Distributor: Debian Synopsis: access denied when accessing webdav share Bugzilla-Product: nautilus Bugzilla-Component: general Bugzilla-Version: unspecified Description: Description of Problem: When I try to connect to mediacenter.gmx.de (where I have access to a secure webdav share), either by typing in the URI davs://mediacenter.gmx.net or davs://****:****@mediacenter.gmx.net in the Open Location dialog, or by specifying the data in the Connect to Server dialog, I get an error message: davs://****@mediacenter.gmx.net konnte nicht angezeigt werden. Der Zugriff wurde verweigert. (davs://... could not be displayed. Access has been denied.) The same happens for unsecured webdav. There isn't even a dialog that asks my password. The webdav share works with cadaver, an ftp-like command line tool. Steps to reproduce the problem: 1. Click File, Open Location 2. Type in "davs://mediacenter.gmx.net" Actual Results: The above error message. Expected Results: A dialog box asking for my login and password. How often does this happen? Everytime. Additional Information: Nautilus 2.8.0 nautilus 2.6 used to crash when trying this. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-09-19 05:24 ------- Unknown platform unknown. Setting to default platform "Other". Unknown milestone "unknown" in product "nautilus". Setting to default milestone for this product, '---' The original reporter of this bug does not have an account here. Reassigning to the person who moved it here, unknown@bugzilla.gnome.org. Previous reporter was lathander@gmx.de. Setting to default status "UNCONFIRMED". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
On Sun, Sep 19, 2004 at 12:59:35PM +0200, Carlos Perello Marin wrote: > On Sun, 2004-09-19 at 11:10 +0200, Sebastian Seifert wrote: > > When I try to connect to mediacenter.gmx.de (where I have access to a > > secure webdav share), either by typing in the URI > > davs://mediacenter.gmx.net or davs://****:****@mediacenter.gmx.net in > > the Open Location dialog, or by specifying the data in the Connect to > > Server dialog, I get an error message: [...] > > The webdav share works with cadaver, an ftp-like command line tool. > Are you sure your dav server is directly at the root directory? > > I'm using the webdav shares since long ago without problems: > > davs://webdav.pemas.net/carlos works, it opens a dialog asking for my > user + password. > > but if I use davs://webdav.pemas.net/ then it fails. I think you have > that problem, perhaps cadaver handles it in a better way than nautilus. > > It worked for me with and without ssl. The website states that "https://mediacenter.gmx.net" is the url to be used for webdav access with Windows. If I look at this URL with firefox, I have to log in with username and password, before it gives an error message "The requested URL / was not found on this server.". But Firefox is a web browser, not a webdav client... Anyway, nautilus doesn't even ask for a login. When I capture the data nautilus sends (by connecting to dav://localhost:12345 and running netcat -l -p 12345), it looks like this: PROPFIND / HTTP/1.1 Host: localhost:12345 User-Agent: gnome-vfs/2.8.0 neon/0.24.6 Keep-Alive: Connection: TE, Keep-Alive TE: trailers Depth: 0 Content-Length: 275 Content-Type: application/xml <?xml version="1.0" encoding="utf-8"?> <propfind xmlns="DAV:"><prop> <getlastmodified xmlns="DAV:"/> <creationdate xmlns="DAV:"/> <resourcetype xmlns="DAV:"/> <getcontenttype xmlns="DAV:"/> <getcontentlength xmlns="DAV:"/> <getetag xmlns="DAV:"/> </prop></propfind> If I paste this into 'telnet mediacenter.gmx.net 80', I get: HTTP/1.1 401 Unauthorized Date: Sun Sep 19 15:08:29 2004 Server: GMX-DAV-Proxy Content-Length: 8028 WWW-Authenticate: Basic realm="GMX MediaCenter" [...] which is about the same response that cadaver gets on its request. Cadaver's request itself looks quite different: OPTIONS / HTTP/1.1 Host: localhost:12345 User-Agent: cadaver/0.22.1 neon/0.24.5 Keep-Alive: Connection: TE, Keep-Alive TE: trailers Anyway, I think nautilus ought to ask for my username and password, since it receives a http 401. Even if the path is incorrect, which I doubt. Sebastian
This is most likely a bug in the gnome-vfs http/webdav method, so I'm reassigning.
Yeah this mediacenter.gmx.net issue is a known one. I hope I can fix it some time soon.
*** Bug 300080 has been marked as a duplicate of this bug. ***
*** Bug 168758 has been marked as a duplicate of this bug. ***
*** Bug 306699 has been marked as a duplicate of this bug. ***
*** Bug 307114 has been marked as a duplicate of this bug. ***
*** Bug 308956 has been marked as a duplicate of this bug. ***
Any progress? This bug is almost one year old now :(
Well, I think this bug is the same as or related to Bug 304736 filed against Nautilus 2.10, where I have posted more information. I think Nautilus' crash is the result of a lack of error handling for an error result of gnome-vfs occuring at an unexpected point of time. However, the error result (GNOME_VFS_NOT_FOUND) possibly should not occur at that point of time: just after opening the WebDAV share successfully (something that returns GNOME_VFS_OK), another access is performed which fails but possibly should not fail (the failure code is GNOME_VFS_NOT_FOUND). Nautilus then (incorrectly?) marks the object describing the WebDAV folder as non-existant, but (in a race condition) still tries to update "bookmark information", which triggers an assertion failure if the non-existant flag is set. If the non-existant flag is reset manually using gdb before the assertion triggers, WebDAV access works PARTIALLY. There is still something fishy about folders and their mime types.
Ubuntu bug about this: http://bugzilla.ubuntu.com/show_bug.cgi?id=18602
I hate this bug. Seriously. :/ Last time I checked it was due to broken gmx webdav proxy bla which was just too ugly to work around. Maybe things have changed. To bad I dont have any gmx login available :/ Sebastian, anyway you could get me some ethereal, tcpdump information (ohh wait its https:// only right?) Maybe turning on debugging in the http method could work. Any chance you could do that?
*** Bug 355121 has been marked as a duplicate of this bug. ***
If it helps speed things up, I would happily create a fresh GMX account and pass the credentials to one of the developer. Please let me know, if I should do so. BTW: Konqueror groks the GMX mediacenter just fine.
O.K. I've now created a new GMX account for testing purposes. Christian, if you would like to test, please let me know.
Hello, to repeat my previous message: If anyone of the developers intends to examine this bug but does not want to go through the procedure of registering a GMX account - I have created one, I will pass you the credentials, if you contact me. This bug is quite annoying, as the only fully working Webdav client is Konqueror. There is also Cadaver, a command-line client, which seems to have issues with UTF8. Given that Konqueror/kioslaves works just fine, it cannot be impossible to fix this...
Are you actually sure you are hitting this bug, and not bug 329956? I haven't been able to find anything wrong with gnome-vfs in this regard. (In no way does this mean that it wouldn't be nice to have a dev look at it, or at least give people asking for it some directions where to start looking, but you might be barking up the wrong tree here...)
Thanks for the pointer to bug 329956. My technical understand may be too limited to know better, but I cannot avoid the impression that both reports are about the same issue. So shouldn't one be marked as a dupe of the other?
No. This bug is about a problem with WebDAV is gnome-vfs (which may be fixed in current versions, but some of those who had the original issue would need to confirm that), while the reports in 329956 specifically mention that gnome-vfs access works fine, but nautilus does not.
Well, it is not only nautilus. As far as I am concerned, loading e.g. a text file into gedit also fails - if there are spaces in the path.
opening a file with spaces in the path in gedit works fine here. both davs://<UID>@mediacenter.gmx.net/Sonstige Dateien/somefile.txt davs://<UID>@mediacenter.gmx.net/Sonstige%20Dateien/somefile.txt typed in the "Location" textentry in the filepicker works. (the title bar shows that the fpicker/gedit convert the space into %20 - and in the second case encode the % as %25 resulting in davs://<UID>@mediacenter.gmx.net/Sonstige%2520Dateien/somefile.txt which still works to open (& save) the file. When using File|Open Location however, the one with the space doesn't work, I have to encode it myself. (so only davs://<UID>@mediacenter.gmx.net/Sonstige%20Dateien/somefile.txt works) so: kind of works as expected, although the Open Location thing should encode the space just as the File-dialog does, but that's more a bug for gedit..
This bug seems to turn up again with the new GVFS It's reported in Launchpad here: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/182674 I don't know if it is of any use, but I hope this could be fixed. Sense Hofstede
gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome. If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs. @Bugzilla mail recipients: query for gnome-vfs-mass-close to get rid of these notification emails all together. General further information: http://en.wikipedia.org/wiki/GVFS Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html