I have a Dav server running with PHP SabreDav (code.google.com/p/sabredav/wiki/Windows) on Cherokee at an HTTPS secured URL. It's set to use https, and uses Digest Authentication. I can log in with multiple browsers and a few third party clients (BitKinex and Java AnyClient can connect and browse as well, caveats below).
However, when attempting to log in with Windows 7 (surprise, surprise), it asks for my password twice, then tells me that my folder is invalid.
- I have verified that the server is using Digest authentication.
- I've verified multiple times that third party software can connect.
- I even went out and bought a GoDaddy SSL certificate so my SSL wouldn't be self signed anymore.
- I've applied the registry hacks here: support.microsoft.com/kb/943280 (Note that the article says the "fix" already exists for Windows 7, I just need magical registry hax to get it to work)
- I've applied the registry hacks here: support.microsoft.com/kb/941050
- I've applied the registry hacks here: support.microsoft.com/kb/841215 (Supposedly allows Basic Auth, which shouldn't apply, but why not?)
All to no avail; Windows continues to ask for my password twice, then state that "The folder you entered does not appear to be valid. Please choose another."
Try the command line? Sure:
- I've attempted to access with NET USE "https://dav.example.com/" password /USER:me (System error 59)
- I've attempted to access with NET USE "https://dav.example.com/" (System error 1790)
- I've attempted to access with NET USE "https://dav.example.com/subdir/" password /USER:me (System error 59)
- I've attempted to access with NET USE "https://dav.example.com/subdir/" (System error 1790)
- For good luck: ping dav.example.com … works. And again, web browsers can access the share just fine, so can third party tools.
Best I can tell at this point is "HAHA, NO WEBDAV FOR YOU ON WINDOWS 7" which would be fine except everyone who will be using this application… uses Windows 7. And most are not as persistent or pugnacious as I am.
I feel like I've burned through every random suggestion I've found anywhere in the first 10 pages of Google on every search term I can think of. Any ideas? I need it to be Webdav, I need it to be over HTTPS, and I really do need a method to access it from Windows 7.
EXTRA DETAIL:
However, the "third party" programs I've tried have either been buggy, incomplete, or have silly … "glitches." For example, BitKinex seems to fixate on any http error codes sent, so if there's a glitch reading a directory, BAM, that directory is always listed empty. Long directory listings also show up as blank, even though the transfer panel shows that directory listing is still taking place.
In any case, BitKinex is useless for development purposes for the reasons above. And besides, I'm building this for people other than myself, people who will want to get this dav share working "the regular way."
Best Answer
I hate WebDAV.
I earned this hate during the process of getting WebDAV support onto my File Serving cluster. This is based on Server 2008 / IIS7, with the WebDAV plugin for IIS. It's clunky, and each individual WebDAV client out there expects to be able to talk to the WebDAV server over their own custom mix of the following:
http://davhost.example.com/, it has to connect tohttp://davhost.example.com/root/WinXP and Win7 behave differently. Early WinXP versions can't talk HTTPS well at all. Some Windows versions, I forget which at the moment, only did session tracking via HTTP headers. Since I have a lot of OSX in my environment, 10.3, 10.4, 10.5, and 10.6 all subtly change what they support in terms of server capabilities. And of course, Gnome has its own requirements which plague our few Linux users.
I. Just. Can't. Win.
Right now I have Windows 7 and WinXP working just fine when serving WebDAV out of IIS7. It took a lot of crow-bar, but it's working. OSX works mostly for newer versions. Everyone else takes their chances.
Windows expects certain WebDAV verbs to be available. Check what your Win7 clients are getting when they attempt to connect and backtrack the error. If they're not getting one, it's a sign that the Windows host doesn't like the environment for some reason; perhaps you need to change session-tracking methods or you need to ensure your DAV hosts are in the correct IE Security Zone. Looking at the access logs is what allowed me to backtrack what Windows was expecting from a WebDAV server.
You'd think that doing WebDAV out of IIS to Windows clients would be simple, but you'd be mistaken like me.