我有一个Dav服务器，使用HTTPS安全的URL在Cherokee上运行PHP SabreDav（ code.google.com/p/sabredav/wiki/Windows ）。 它被设置为使用https，并使用摘要式身份validation。 我可以login多个浏览器和一些第三方客户端（BitKinex和Java AnyClient可以连接和浏览，以下注意事项）。
但是，当试图用Windows 7login时（惊喜，惊喜），它要求我的密码两次，然后告诉我，我的文件夹是无效的。
无济于事; Windows继续询问我的密码两次，然后声明“您input的文件夹似乎不是有效的，请select另一个。”
试试命令行？ 当然：
最好我现在可以告诉的是“HAHA，没有WEBDAV在WINDOWS 7上适合你”这将是很好，除了每个人将使用此应用程序…使用Windows 7.而且大多数不像我一样顽固或好斗。
我觉得我已经在每一个我能想到的search字词的前10页的任何地方发现了任何随机的build议。 有任何想法吗？ 我需要它是Webdav，我需要它通过HTTPS，我真的需要一个方法来从Windows 7访问它。
额外的细节：
然而，我尝试过的“第三方”程序要么是越野车，不完整，要么是愚蠢的“毛病”。 例如，BitKinex似乎注意到任何发送的http错误代码，所以如果读取目录BAM的故障，该目录总是被列为空。 长目录列表也显示为空白，即使传输面板显示目录列表仍在发生。
无论如何，出于上述原因，BitKinex对于开发目的而言是无用的。 另外，我正在为自己以外的人build立这个平台，那些想要得到这个平台的人们“定期的工作”。
我讨厌WebDAV。
在WebDAV支持到我的文件服务群集的过程中，我赢得了这种仇恨。 这是基于Server 2008 / IIS7和IIS的WebDAV插件。 它很笨拙，每个单独的WebDAV客户端都希望能够通过自定义的以下方式与WebDAV服务器通信：
http://davhost.example.com/ ，它必须连接到http://davhost.example.com/root/ WinXP和Win7的行为有所不同。 早期的WinXP版本不能很好地使用HTTPS。 有些Windows版本，我忘记了目前只通过HTTP头进行会话跟踪。 由于我在我的环境中有很多OSX，10.3,10.4,10.5和10.6都巧妙地改变了他们在服务器function方面的支持。 当然，Gnome有自己的要求，困扰我们的Linux用户。
我只是。 不能。 赢得。
现在我有Windows 7和WinXP的工作，当IISD提供WebDAV时很好。 它花了很多的时间，但它的工作。 OSX主要用于较新的版本。 其他人都有机会。
Windows期望某些WebDAV动词可用。 检查您的Win7客户端在尝试连接并回溯错误时获取的内容。 如果他们没有得到一个，这是一个迹象表明，Windows主机由于某种原因不喜欢环境; 也许您需要更改会话跟踪方法，或者您需要确保您的DAV主机位于正确的IE安全区域中。 查看访问日志可以让我回溯Windows对WebDAV服务器的期望。
你会认为将WebDAV从IIS迁移到Windows客户端会很简单，但是你会像我一样误会。
WebDAV的效果很好，除了Windows WebDAV客户端坏了。 例如，Windows迷你redirect器摘要身份validation已损坏。 出于某种原因，似乎可以从命令行映射客户端。
以下页面详细解释了这一点： http : //barracudaserver.com/products/BarracudaDrive/tutorials/mapping_windows_drive.lsp
使用另一个WebDAV客户端或使用实现会话URL的BarracudaDrive等WebDAV服务器。 您使用浏览器login并在映射驱动器时使用浏览器提供的会话URL。
我遇到了同样的问题，并得到解决。 简而言之，这个问题有几个常见的原因。
我在博客上详细解释了这个问题：
为什么摘要身份validation在Windows 7 Mini-redirector中失败
2014年6月2日
问题在于：您有一个WebDAV服务器，它在使用摘要式身份validation时几乎可以与除Windows 7迷你redirect器之外的所有WebDAV客户端配合使用。
无可否认，为什么selectDigest Authentication并坚持使用Windows 7迷你redirect器本身可能是一个争论。 本文不讨论这样的devise选项。 它只是想分享我在微软的WebDAV客户端挣扎中学到的东西，以便其他人不会在未来付出代价。
从Win7连接到WebDAV服务器的常用方法是打开Windows资源pipe理器窗口，将networking驱动器映射到服务器的URL。 如果服务器受到摘要式身份validation的保护，则会提示您input用户名和密码。 您input，提交，然后popup另一个框，再次询问您的凭据。 你继续input正确的凭证3次，Windows不会让你继续尝试。
这是我面临的问题。 让事情变得更有趣，当networkingdebugging器的提琴手出席时，这个问题可能会被掩盖。 也就是说，只要小提琴手是中间的人，它就行得通。 否则，它停止工作。
我试图从很多方面来处理这个问题，后面我将会介绍这个问题，但都没有解决问题。
当我发现Fiddler有两个与连接相关的选项：“重用客户端连接”和“重用服务器连接”时，我认为是前进了一大步。 我之前描述的工作/不工作场景可以通过打开/closures“重新使用客户端连接”来重现，而不必完全closures提琴手。
通过比较我的会话与Win 7客户端和Apache之间会话的连接模式，区别在于我的WebDAV服务器总是断开连接，特别是在返回400个HTTP状态代码系列时，例如401 Unauthorized。 修复很简单，保持401上的连接立即解决问题。
我的同事，一个经验丰富的开发人员告诉我，这是微软的一个古老的bug，这个微软已经存在了超过12年，但是他们从来没有修复过它。 客户端启动一个TCP连接C，然后发送一个普通的HTTP请求，服务器将会生成一个401响应和“WWW-Authenicate”头，包括摘要信息，并将其发送回客户端。 在这个特定的时刻，服务器可以select保持连接活动，或者丢弃它，不pipe之前的“连接”，“保持活跃”标题说什么。 假设服务器决定放弃连接，当401响应到达win7客户端时，它将计算摘要式身份validation所需的“授权”头，然而，win7客户端坚持通过先前创build的连接C发送该头，如果C被破坏，它将开始一个新的连接，C'，发送一个纯粹的请求，没有“授权”头。 在这一点上，你应该能够预测接下来会发生什么，并解释为什么存在多个login问题。
为了总结上述过程，Win 7客户端将仅在以下两个条件下发送“授权”头：1.在提交凭证之后，即当第一次创build“授权”头时; 2.连接是通过它发送原始普通请求并获得401响应的相同连接。
HTTP是一种无状态协议，客户端和服务器都不应该依赖任何状态，例如连接状态。 一个强大的服务器，例如启用了WebDAV模块的Apache，或者一个健壮的客户端，例如Cadaver，能够处理一个僵化的客户端，比如win7客户端，或者一个僵硬的服务器，比如我的服务器。
WebDAV与摘要很难得到正确的，我只看到两个服务器做到目前为止，一个是stream行的Apache DAV模块，另一个是修复这个bug后我的服务器。
Win 7的WebDAV支持确实很糟糕。 您的客户还有许多其他的select。 Cadaver是Linux / Unix平台上的优秀开源WebDAV客户端，Mac内置WebDAV支持，Cyber Duck，BitKinex等第三方客户端都是不错的select。 但是，如果您的大部分客户仍然依靠Windows平台，Win7迷你redirect器仍然是他们访问WebDAV服务器的最便捷方式，您可能仍然需要为客户服务。 下面是一些其他可能的原因，不起作用的摘要式身份validation。
- 你的validation逻辑是错误的，所以它甚至不会接受正确的凭证
- DAV响应正文使用默认命名空间，请参阅下面的链接进一步的细节： http : //www.greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-namespace-handling https：//问题。 apache.org/bugzilla/show_bug.cgi?id=49428
- 如果您正在发送“Authentication-Info”标题，请务必使其工作如果>所有发送“Authentication-Info”标题，请务必使其工作
如果所有这些都不能帮助你，下面是我find一些有用的方法来寻找根本原因：1.使用Fiddler，ngrep捕获和研究stream量2.使用开源客户端和服务器作为基准。 你可以通过阅读代码来了解进程的机制; 代码是经过充分testing和可靠的3.扩大你的观点。 如果HTTP通信不起作用，原因可能是stream量（内容），超时（定时），连接（上下文）等。 4.记住旧的事实：HTTP是无状态的。 根据所添加的任何国家，不应该作出任何假设5.仔细阅读RFC，不要犹豫，在网上提问
总而言之，摘要式身份validation是一种比基本更强的scheme。 从现在的安全技术来说，基本上没有提供任何保护，“摘要”本质上容易受到中间人的攻击。 请仔细考虑你使用哪个安全环境。
在microsoft.com上有一个kb说，如果有一个像https://www.example.com/webdav那样是一个webdav的子目录，但父母不是一个webdav win7和win服务器08将尝试对不是webdav的父进行身份validation。 该修复程序在这里： http : //support.microsoft.com/kb/2560598
我确认，如果按照这种方式进行设置，它确实按预期工作。 我认为另一种select是使用指向您的webdav目录的webdav子域名，例如https://webdav.example.com 。
BitKinex是唯一的程序，我已经发现，将做webdav到Windows 7自签名证书。我有一些希望的Cyberduck，但发现它有同样的问题，提示input密码两次，死亡。 显然BitKinex的人们已经发现了win7 webdav的一些黑暗的秘密，只有秘密社团的某些成员才能发布自我签名。 大声笑BitKinex做这个工作真棒，有调度和一切。
我尝试了基本和摘要式身份validation（通过https），并没有任何与Windows 7客户端工作。
我发现迄今为止没有第三方客户端在Windows 7上工作的唯一方法是放弃用户名/密码身份validation，并将其replace为客户端证书身份validation。 我的目录节现在看起来像这样：
<Directory /dav/dir> AllowOverride None Options Indexes -Includes FollowSymLinks DirectoryIndex None SSLRequireSSL 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") DAV On </Directory>
SSLRequire节应根据您自己的要求进行修改 。
一旦完成，请在客户端安装证书。 我使用TinyCA2生成和分发自己的证书。 或者只是使用第三方authentication机构。
我们在Apache反向代理的服务器上有一个https webdav。 和Windows上的webclient服务不启动，安装失败，0x80070043networking名称…
我们通过将第一个请求vom windows资源pipe理器的答案重写为200 OK而不是redirect302来解决这个问题。然后webclient将启动并挂载成功。
apache规则示例：
RewriteEngine On RewriteCond %{REQUEST_URI} ^(/)$ [NC] RewriteCond %{REQUEST_METHOD} OPTIONS RewriteRule ^(.*)$ $1 [R=200,L]
更新：我们有两次login相同的问题，我解决了它与添加以下的Apache虚拟主机configuration（反向代理）：
DefaultType None