WebDAV over https not working anymore

I certainly appreciate the quick reply. I did put in a request with our IT folks to see if it could be tweaked. There are resource bundle/parameter file things lurking on my hardrive. I'm tempted to find a way to hack one of those. Something tells me that may not be enough 🙂

Cheers!

Even if you could patch it, it may not fix it. We were running webdav with no directive in place for the older version of WebDAVFS and we never had any issues with it. So even if you did spoof the user agent header then it may not work if there is a bug in the newer version requiring redirect-carefully.

Also, we did have a few more issues with our fix. I ended up having to add two lines, one for WebDAVLIb/1.* and another for WebDAVFS/2.*. It appears that when you first login the user agent is identified as WebDAVLib, then when you actually start accessing files it changes to WebDAVFS.

We are still having intermittent issues with some files showing up either blank when they are opened, or with files seeming to disappear off the share. However, it has only happened a couple of times and its not nearly as bad as before, but it would be nice if it would get fixed.

One thing that is nice, is that when it is working it is noticeably faster than the last version of Mac OS X.

this not solve the problem, I imported the certificate into keychain, trusted it but it not enable the writing modes. I'm always get an unexpected error -43 if I try to change something into webdav mounted folder.

May be a bogus webdav implementation?

The error -43 is a completely different error which I believe has to do with some older version if os x server with regards to renaming folders. If you can't find the solution by googling, you may want to start a new discussion with that in the title to see if you can get a response.

Yes you are right the error was on renaming, it comes while I try to rename file. But the problem is that I'cannot use the webdav mounted share like a read/write disk. If I copy a file into it I get the error -36 while I edit and save a file the editor give me the file not found error.

Te server is on network and shouldn't be an osx server (may be linux). But ok I try to open a new tread.

Thanks

It works if you don't write https in the address. Only http. Then Webdav servers connect using the cmd K function also in Mountain Lion...

... same problem here. Any solution until now?

Only write http in the server address. Leave out the "s" then it works

nope - does not work, still same error message: "Check the server name or IP-address and try again."

I should have added that this error message appears after entering unsername and password. So - there already was a connection to the server.

without "s" there's no solution, and it's a non sense a connection without protocol encryption layer!

In my specific case I got WebDav working over SSL (using 10.8.1) by adding nokeepalive to the BrowserMatch statement in the Apache HTTP Server config.

BrowserMatch "^WebDAVFS/2.0" nokeepalive redirect-carefully

Obviously forcing nokeepalive isn't beautiful at all, but at least it's working again.

https://sd2dav.1und1.de does a connect, but transfer of files do not work (jpg files are not detected as jpeg)

https://webdav.mediencenter.t-online.de does no connect with 8.1 (with Lion it was possible to connect but if you transferd a lot of files, the connection was terminated)

These sites do not use self signed certificates and work with a lot of other webdav clients (example cyperduck)

German Telekom did some modifications (they write that Mountain lion does it wrong) but several other WebDav connections do not work still (example the big provider 1und1 in Germany)

I m having somewhat related issue -similar to what the user 'Ringo De Smet' mentioned, with native webdav client in 10.8.2. I can successfully connect to a webdav share(using finder, connect to server), but when I copy a file to webdav share, soon after the copy completes, the client sends delete requests to the server when no such gesture(delete) is done. This only happens in 10.8 and worked perfectly fine in 10.7

I see explicit delete requests from client being logged in server logs. Seems like a bug to me, any solutions/pointers to the problems would be appreciated.