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:

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.


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."

7 Answers 7


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:

  • Transport mechanism: HTTP or HTTPS
  • Session tracking: Cookies or HTTP-headers
  • Authentication: Basic, Digest, Kerberos, or NTLM authentication
  • Custom-port support may or may not be included.
  • The ability to connect to a root directory may or may not be present; WinXP certainly can't connect to http://davhost.example.com/, it has to connect to http://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.

  • I've added even more logging to the PHP Dav script, and best I can tell, Windows 7 isn't even getting through the authentication of the webserver... I swear, it looks like Windows isn't even sending any authentication headers at all and just fails to try to access the server. The question then is... where might I find Windows 7's access logs so I can see what it's up to... or not, as the case may be.
    – AutoDMC
    Nov 29, 2010 at 14:03
  • @AutoDMC Windows doesn't keep access logs for that kind of thing. At least not where I've found. That would be useful. Another test I found useful was attempting to browse the WebDAV source from IE (not FF, IE). Sometimes that gives better error reporting than WebDAV does, as Windows uses the IE engine to drive WebDAV.
    – sysadmin1138
    Nov 29, 2010 at 15:11
  • Forgive my ignorance, but I'm not generally an IE user. It looks like "Open as Web Folder" is gone as of IE7, 8, and 9, which of course are the only versions I have on any boxes anywhere (blogs.msdn.com/b/askie/archive/2009/03/20/…) Is there a different method you were intending I troubleshoot with? .......... I can connect to the webdav through Internet Explorer in web-view-mode just fine, but that's a display mode of the PHP site, not an actual interactive dragndrop shell, which is what I need.
    – AutoDMC
    Nov 29, 2010 at 15:49
  • @AutoDMC That webview mode is kind of what I was thinking of. It proves that Win7 can authenticate in some way at all. The next step is figuring out what auth/session differences exist between that view and php-webdav, and finding a flavor Win7 likes.
    – sysadmin1138
    Nov 29, 2010 at 17:25
  • When I say I can see the "web view," as a non-IE user, SabreDAV has it's own "html view driver." This works in all browsers. If there's a special IE mode what allows you to browse a DAV share, I don't know if it. It appears that the "Web Folder" option under "File > Open" has been removed in IE7 and better. ........... IE can authenticate with Digest auth to display the html view generated by SabreDAV, but I've not been able to find a direct method to access the share with IE.
    – AutoDMC
    Nov 29, 2010 at 18:40

WebDAV works great, except for that the windows WebDAV clients are broken. For example, the Windows Mini Redirector's Digest authentication is broken. For some reason, it seems that it is possible to map the client from the command line.

The following page explains this in detail: http://barracudaserver.com/products/BarracudaDrive/tutorials/mapping_windows_drive.lsp

Use another WebDAV client or use a WebDAV server such as BarracudaDrive that implements session URL's. You login using a browser and use the session URL provided by the browser when mapping the drive.


I ran into the same problem and got it resolved. To put simply, there are several common causes of the issue.

  1. dav response namespace issue
  2. connection issue

I explained this problem in details on my blog :

Why Digest Authentication Fails in Windows 7 Mini-redirector

JUN 2ND, 2014

Here is the problem: you have a WebDAV server, it works with almost all WebDAV clients except Windows 7 mini-redirector when using Digest Authentication.

Admittedly, why choosing Digest Authentication and sticking with Windows 7 mini-redirector in itself might be a debate. This article does not discuss about design options such as this. It only aims to share what I’ve learned struggling with the Microsoft’s WebDAV client so that other folks won’t pay the price in the future.

The usual way to connect to a WebDAV server from Win7 is to open up a Windows Explorer window, map a net drive to the url of the server. If the server is protected by Digest Authentication, you will be prompted to enter your username and password. You type in, submit, and it pops up another box, asking you for credentials again. You keep typing the correct credentials 3 times, and Windows will not allow you keep trying.

This is the problem I was facing. Making things more interesting, the problem could be masked when Fiddler the web debugger is present. That is to say, whenever Fiddler is the man in the middle, it works; otherwise, it stops working.

I tried to approach this problem from many directions which I will cover later in this post, but all didn’t solve the problem.

I was a big step forward when I discovered that Fiddler has two connection related options: “Reuse client connection” and “Reuse server connection”, both are turned on by default for peformance reason I suppose. The working/not working scenarios I described earlier could be reproduced by toggle “Reuse client connection” on/off, without shutting down the Fiddler completely.

By comparing the connection patterns of my session with the session between Win 7 client and Apache, the difference turned out to be that my WebDAV server always drops the connection, especially upon returning 400 series of HTTP status code, for example, 401 Unauthorized. The fix is simple, keeping the connection alive upon 401 solves the problem immediately.

My coworker, a seasoned developer, told me this is an ancient bug of Microsoft, which existed for over 12 years but they never fixed it. The client starts a TCP connection, C, and then sends a plain HTTP request, the server will generate a 401 response together with “WWW-Authenicate” header, including the Digest information, sends it back to the client. At this particular moment, the server has the choices to either keep the connection alive, or drops it, regardless of what the “Connection”, “Keep-Alive” header says earlier. Say the server decided to drop the connection, when the 401 response get to the win 7 client, it will compute an “Authorization” header needed for Digest Authentication, however, win 7 client insists to send this header along through the connection C created earlier, if C is broken, it will start a new connection, C’, send a plain request WITHOUT the “Authorization” header. At this point, you should be able to predict what is going to happen next and to explain why the multiple login problems exist ever.

To summary the above process, the Win 7 client will ONLY send the “Authorization” header upon two conditions: 1. right after you submit the credentials, i.e. when “Authorization” header was created the first time; 2. the connection was the same connection through which it sent the original plain request and got the 401 response.

HTTP is a stateless protocol, neither client nor server should rely on any states such as the connection status. A robust server such as Apache with WebDAV module enabled or a robust client such as Cadaver is able to cope with a rigid client such as win 7 client, or a rigid server such as my server.

WebDAV with Digest is hard to get right, I only saw two servers made it right so far, one is the popular Apache DAV module, the other is my server after fixing this bug.

Win 7 WebDAV support is indeed crappy. There are many other choices for your customers. Cadaver is an excellent open source WebDAV client on Linux/Unix platforms, Mac has build-in WebDAV support, and third party clients such as Cyber Duck, BitKinex, etc. are all good choices. However, if a large portion of your customers are still relying on Windows platform thus Win7 mini-redirector is still their most convenient way to access their WebDAV server, you may still need to make it work for the customers. Here are some other possible causes that the Digest Authentication that does not work.

  1. Your authentication logic is implemented wrong so it won’t accept even correct credentials
  2. The DAV response body uses default namespace, refer to the links below for further details: http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-namespace-handling https://issues.apache.org/bugzilla/show_bug.cgi?id=49428
  3. If you are sending “Authentication-Info” header, be sure to make it work If > all sending “Authentication-Info” header, be sure to make it work

If all of these does not help you, here are some approaches I found useful when hunting for the root cause: 1. Use Fiddler, ngrep to capture and study the traffic 2. Use open source clients and servers as base reference. You could know the machinery of process by reading the code; the code is well tested and reliable 3. Expand your perspectives. If HTTP communication does not work, the reason might be the traffic (content), timeout (timing), connection (context),etc. 4. Remember the old fact: HTTP is stateless. No assumptions should be made based on any states added 5. Read the RFC carefully and do not hesitate to ask questions online

To wrap up, Digest Authentication is a scheme stronger than Basic. Basic literally provides no protection in terms of today’s security technologies and Digest is inherently vulnerable to man in the middle attack. Please think carefully which security context are you using them in.


There is a kb on microsoft.com that says if there is a child directory in the url such as https://www.example.com/webdav that is a webdav but the parent is not a webdav win7 and win server 08 will try to authenticate against the parent that is NOT a webdav. the fix is here: http://support.microsoft.com/kb/2560598

I confirmed that it does work as intended if setup this way. I think the other option would be to use a webdav subdomain such as https://webdav.example.com that points to your webdav directory.


BitKinex is the only program I have found that will do webdav to a self signed certificate on windows 7. I had some hopes for Cyberduck but found it has the same problem, prompts for password twice more and dies. Apparently the BitKinex folks have discovered some deep dark secret of win7 webdav with self signed that is only let out to certain members of the secret societies. LOL BitKinex does the job awesome and has schedulers and everything.


I tried both basic and digest authentication (over https) and could get nothing to work with a Windows 7 client.

The only way I have found so far of getting this working on Windows 7 without a third-party client was to ditch username/password authentication and replace it with client certificate authentication. My directory stanza now looks like this:

<Directory /dav/dir>
AllowOverride None
Options Indexes -Includes FollowSymLinks
DirectoryIndex None
SSLVerifyClient require
SSLVerifyDepth 10
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Org 1" or \
  (%{SSL_CLIENT_S_DN_O} eq "Org 2" and %{SSL_CLIENT_S_DN_OU} eq "Org Unit 1")

The SSLRequire stanza should be modified as per your own requirements.

Once this is done, install a certificate on the client side. I generate and distribute my own certificates using TinyCA2. Or simply use a third-party certificate authority.


we have a https webdav on a server behind an Apache reverse proxy. and the webclient service on windows does not starts, mount fails with 0x80070043 network name ...

we solved this by rewrite the answer of the first request vom windows explorer to a 200 OK instead of a redirect 302. then webclient will start and mounting succeed.

apache rules example:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^(/)$ [NC]
RewriteRule ^(.*)$ $1 [R=200,L]

Update: we had the same issue with twice Logins and i solved it with adding following to the Apache vhost config (on reverse proxy):

DefaultType None

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.