> Steps to reproduce:
> Actual results:
> Expected results:

...these exist for a reason.

Ok, apologies for not filling out all fields, I am still new at this, but actually all the relevant info are in  the "Please describe the problem" section. Or at least this is what I thought. In other words:

>>Steps to reproduce:<<
1. open nautilus
2. input the following URI in the location field:
davs://user@ip.address:port#/dav/share
3. enter username and passwords as requested by nautilus

>>Actual results:<<
the following error pops up:

Could not display "davs://user@ip.address:port#/dav/share".
Error: Not a WebDAV enabled share
Please select another viewer and try again.

>>Expected results<<
mounting of remote share

I can confirm this bug on a fresh install of Ubuntu 9.04, Gnome 2.26.1

I've determined that none of the webdav features in the "Connect to server..." dialog, or from nautilus File menu, or the location bar work.

for testing, check out http://test.webdav.org, they have test webdav shares for testing public access, secure connections, etc.

going to "Places > Connect to Server... > Secure Webdav(HTTPS)" and entering
Server: test.webdav.org
Port: Blank
Folder: /auth-basic/
username: (user1 through user9 are available... i used user1... password is the same as the username)
generates either- "HTTP Error: Cannot connect to destination" or "Error: Not a WebDAV enabled share"

Same with unauthenticated davs, digest authentication.

however, if i don't enter a user, then a dialog box pops up and asks for my username and password.  odd?

the redirect test servers on the site return the appropriate messages (i.e. found for 302 found, moved permenantly for 301 moved permanantly, etc)

In Ubuntu 9.10 it is half solved. I mean:

It connects to the webdav sometimes.

When you copy files and directories from the webdav to the local disks the only ones that are copied are the files and the derictories are shown like html files.

It is not problem from the server because I tried to tho the same in a coputer with kde 3.5 and it worked.

I hope you'll solve the bug soon.

Marc,

The directory copy behavior is described in Bug #551339. If the original connection issue is fixed, this bug (Bug #582219) should be closed.

I just tried again, I do not manage to connect at all, so as far as I am concerned the issue is not fixed, no change since last reported, no change after upgrading to Karmic.

sim909, can you please provide debug logs for you connection attempt. The easiest way to do that is to the env variable GVFS_HTTP_DEBUG to "all" ("export GVFS_HTTP_DEBUG="all") and then restart gvfsd with "gvfsd --replace".
Re-open with info, please.

Created attachment 149600 [details]
Log from gvfs

Debug log after setting GVFS_HTTP_DEBUG="all"

Very happy to see a gvfs developer coming in...!
Did as Christian Kellner suggested. These are the commands issued:

++++++++++++++
> gvfs-mount davs://192.168.1.23:6081/dav/o
Enter password for BarracudaDrive
User: username
Password:
Enter password for BarracudaDrive
Password:
Enter password for BarracudaDrive
Password:
Error mounting location: Not a WebDAV enabled share
+++++++++++++++

As you can see I repeatedly get asked for a password, and then the resource never gets mounted.

With cadaver I have no issues whatsoever:

+++++++++++++++
> cadaver https://192.168.1.23:6081/dav/o
WARNING: Untrusted server certificate presented for `127.0.0.1':
Certificate was issued to hostname `127.0.0.1' rather than `192.168.1.23'
This connection could have been intercepted.
Issued to: Barracuda Embedded Web Server Demo Certificate, Real Time Logic, 40 Craven Street, Charing Cross, London WC2N 5NG, UK
Issued by: Real Time Logic, 40 Craven Street, Charing Cross, London WC2N 5NG, UK
Certificate is valid from Mon, 20 Jun 2005 21:10:57 GMT to Thu, 18 Jun 2015 21:10:57 GMT
Do you wish to accept the certificate? (y/n) y
Authentication required for BarracudaDrive on server `192.168.1.23':
Username: username
Password: 
dav:/dav/o/> exit
Connection to `share.noventi.net' closed.
+++++++++++++++

Attached is the all the debug log from gvfs.

So from the logs you provided it looks like we get a bunch of 401s in a row until we get banned: "<title>YOU HAVE BEEN BANNED!!</title>". 

Dan, ideas?

Hoping it helps, I will attach the logs that come from the server side.
I will attach logs from both a successful connection with cadaver, and the unsuccessful connection using gvfs. Commands used on the client side are 

> cadaver http://192.168.1.23:6082/dav/o

and

> gvfs-mount dav://192.168.1.23:6082/dav/o

Using the non secure connection this time (for a second I thought that the lack of valid certificate on the server was the problem, but it turns out that is not the issue).

Created attachment 149619 [details]
Server-side log of successful connection using cadaver

Created attachment 149620 [details]
Server-side log of UNsuccessful connection using gvfs

my first guess was going to be "Digest auth doesn't actually work on the server, and cadaver works because it's using Basic auth", although that's apparently wrong since the logs show cadaver is using digest as well. Still, I bet if you disabled digest auth on the server side (not sure if it lets you do that?) then it will start working from gvfs as well. (And you don't really need digest auth since it's SSL-encrypted anyway.)

Still, it would be nice to know why gvfs/libsoup is failing. You don't happen to have non-ASCII characters in your username or password do you?

If not, what might be useful in debugging would be for you to change your password to something trivial, then get logs of connecting with both gvfs and cadaver, and then attach the *exact* WWW-Authenticate and Authorization headers from the logs to this bug, without changing anything, and also include what the password was. Then I can run through the algorithm using that username and password and WWW-Authenticate data and figure out how cadaver is getting the answer that it gets and why libsoup gets something different.

(And don't forget to change your password back afterward :-)

No, unfortunately I can't (or at least I didn't figure out how to) disable digest auth on the server. I did a different test, though: I have access to a webdav enabled apache server, and gvfs connects with no problem.

My username and password are both standard characters.

I did the tests you suggested, I am posting the results in a minute.

Created attachment 149733 [details]
Server-side log of successful cadaver connection

Command: cadaver https://192.168.1.23:6081/dav/o/trashbox

Username: test
Password: test

Created attachment 149734 [details]
Server-side log of UNsuccessful gvfs connection

Command: gvfs-mount davs://192.168.1.23:6081/dav/o/trashbox

Username: test
Password: test

ok, feeding the nonce, etc, from cadaver's request/response into libsoup's algorithm gives the same response as cadaver generates, so it's not a bug in the algorithm.

the only other differences I could notice were that:

    a) gvfs's URI has an extra trailing '/', although it is completely
       consistent about this, so I don't think that's the bug. (If it was
       getting a 404 that would make sense, but not 401.)

    b) libsoup puts quotes around the "nc" attribute, and cadaver does
       not

given that the examples in the digest auth rfc show the nc attribute with no quotes, I suspect this may be the problem; your drive is assuming that the quotes are forbidden rather than optional.

Are you able to build and test your own libsoup? If so, try changing the

		g_string_append_printf (out, ", nc=\"%.8x\"", priv->nc);

line in soup-auth-digest.c to remove the \" before and after the %.8x.

If not, I'll commit this and we'll just keep the bug NEEDINFO until the change works its way down to your distro and you test it.

(probably) fixed in git

(In reply to comment #18)
> 
> Are you able to build and test your own libsoup? If so, try changing the
> 
Not really, I am not that savvy, maybe not a complete newbie, but not far from there. I did try, though: got the source code, modified soup-auth-digest.c, did the usual config, make (had to install many ...-dev packages before that completed without errors) and sudo make install, but with no different results. Not sure if that is what I was supposed to do, so definitely my failure doesn't mean your fix doesn't work. With detailed instructions I will be happy to try your fix...

Or if by any chance you are running Karmic 64 bits, you could just pass me the binaries and tell me where to save them...

Closing as FIXED as per comment #19. Please reopen if this is still an issue.