我有一个运行 PHP SabreDav 的 Dav 服务器（code.google.com/p/sabredav/wiki/Windows) 在 Cherokee 上的 HTTPS 安全 URL 上。它设置为使用 https，并使用摘要式身份验证。我可以使用多个浏览器和一些第三方客户端登录（BitKinex 和 Java AnyClient 也可以连接和浏览，注意事项如下）。
但是，当尝试使用 Windows 7 登录时（令人惊讶的是），它会要求我输入两次密码，然后告诉我我的文件夹无效。
- 我已经验证服务器正在使用摘要式身份验证。
- 我已多次验证第三方软件可以连接。
- 我甚至出去购买了 GoDaddy SSL 证书，这样我的 SSL 就不再是自签名的了。
- 我在这里应用了注册表黑客技术： support.microsoft.com/kb/943280（请注意，文章说 Windows 7 中已经存在“修复”，我只需要神奇的注册表 hack 就可以使其工作）
- 我在这里应用了注册表黑客技术： support.microsoft.com/kb/941050
- 我在这里应用了注册表黑客技术： support.microsoft.com/kb/841215（据称允许基本身份验证，但这不应该适用，但为什么不呢？）
但一切都无济于事；Windows 继续要求我输入两次密码，然后显示“您输入的文件夹似乎无效。请选择其他文件夹。”
尝试命令行？当然可以：
- 我尝试使用 NET USE 访问“https://dav.example.com/“密码 /USER:me（系统错误 59）
- 我尝试使用 NET USE 访问“https://dav.example.com/“（系统错误 1790）
- 我尝试使用 NET USE 访问“https://dav.example.com/subdir/“密码 /USER:me（系统错误 59）
- 我尝试使用 NET USE 访问“https://dav.example.com/subdir/“（系统错误 1790）
- 祝你好运：ping dav.example.com ... 成功。同样，网络浏览器可以正常访问共享，第三方工具也可以。
我现在能说的最好的就是“哈哈，WINDOWS 7 上没有 WEBDAV”，除了所有使用该应用程序的人之外，其他的人都使用 Windows 7。而且大多数人并不像我一样执着或好斗。
我感觉我已经用完了在 Google 前 10 页上找到的所有随机建议，这些建议都是我能想到的。有什么想法吗？我需要它是 Webdav，我需要它通过 HTTPS，而且我确实需要一种从 Windows 7 访问它的方法。
额外细节：
然而，我尝试过的“第三方”程序要么有缺陷，要么不完整，要么有愚蠢的“小故障”。例如，BitKinex 似乎会关注发送的任何 http 错误代码，因此如果读取目录时出现故障，BAM，该目录始终显示为空。长目录列表也会显示为空白，即使传输面板显示目录列表仍在进行中。
无论如何，出于上述原因，BitKinex 对于开发目的而言毫无用处。此外，我是为了其他人而构建的，这些人希望以“常规方式”让此 dav 共享工作。
答案1
我讨厌 WebDAV。
我在将 WebDAV 支持添加到我的文件服务集群的过程中得到了这种仇恨。它基于 Server 2008 / IIS7，带有 IIS 的 WebDAV 插件。它很笨重，并且每个单独的 WebDAV 客户端都希望能够通过他们自己的自定义组合与 WebDAV 服务器通信：
- 传输机制：HTTP 或 HTTPS
- 会话跟踪：Cookie 或 HTTP 标头
- 验证：基本身份验证、摘要身份验证、Kerberos 身份验证或 NTLM 身份验证
- 可能包含或不包含自定义端口支持。
- 连接到根目录的能力可能存在，也可能不存在；WinXP 当然不能连接到
http://davhost.example.com/，它必须连接到http://davhost.example.com/root/
WinXP 和 Win7 的行为有所不同。早期的 WinXP 版本根本无法很好地支持 HTTPS。有些 Windows 版本（我暂时忘了是哪个）仅通过 HTTP 标头进行会话跟踪。由于我的环境中有很多 OSX，因此 10.3、10.4、10.5 和 10.6 都巧妙地改变了它们在服务器功能方面所支持的内容。当然，Gnome 有自己的要求，这困扰着我们为数不多的 Linux 用户。
我。根本。赢不了。
目前，当我使用 IIS7 提供 WebDAV 服务时，Windows 7 和 WinXP 运行良好。虽然费了不少劲，但还是成功了。OSX 大多适用于较新的版本。其他人则只能碰碰运气。
Windows 需要某些 WebDAV 动词可用。检查您的 Win7 客户端在尝试连接时收到什么，并回溯错误。如果没有收到，则表明 Windows 主机出于某种原因不喜欢该环境；也许您需要更改会话跟踪方法，或者您需要确保您的 DAV 主机位于正确的 IE 安全区域。查看访问日志使我能够回溯 Windows 对 WebDAV 服务器的期望。
您可能认为从 IIS 到 Windows 客户端执行 WebDAV 很简单，但您和我一样错了。
答案2
WebDAV 运行良好，只是 Windows WebDAV 客户端有问题。例如，Windows Mini Redirector 的摘要身份验证有问题。出于某种原因，似乎可以从命令行映射客户端。
以下页面详细解释了这一点： http://barracudaserver.com/products/BarracudaDrive/tutorials/mapping_windows_drive.lsp
使用另一个 WebDAV 客户端或使用实现会话 URL 的 WebDAV 服务器（如 BarracudaDrive）。使用浏览器登录并在映射驱动器时使用浏览器提供的会话 URL。
答案3
我遇到了同样的问题并解决了。简而言之，这个问题有几个常见原因。
- dav 响应命名空间问题
- 连接问题
我详细解释了这个问题我的博客：
为什么 Windows 7 微型重定向器中的摘要身份验证会失败
2014 年 6 月 2 日
问题如下：您有一个 WebDAV 服务器，当使用摘要式身份验证时，它可以与除 Windows 7 迷你重定向器之外的几乎所有 WebDAV 客户端一起使用。
诚然，为什么选择摘要式身份验证并坚持使用 Windows 7 微型重定向器本身可能是一个争论。本文不讨论此类设计选项。它的目的只是分享我在使用 Microsoft 的 WebDAV 客户端时所学到的知识，以便其他人将来不会为此付出代价。
从 Win7 连接到 WebDAV 服务器的常用方法是打开 Windows 资源管理器窗口，将网络驱动器映射到服务器的 URL。如果服务器受摘要式身份验证保护，系统将提示您输入用户名和密码。您输入、提交，然后会弹出另一个框，再次要求您输入凭据。您连续输入正确的凭据 3 次，Windows 不会允许您继续尝试。
这是我面临的问题。更有趣的是，当存在 Web 调试器 Fiddler 时，问题可能会被掩盖。也就是说，只要 Fiddler 是中间人，它就会工作；否则，它就会停止工作。
我尝试从多个方向来解决这个问题（我将在本文后面介绍），但都未能解决问题。
当我发现 Fiddler 有两个与连接相关的选项时，我向前迈出了一大步：“重用客户端连接”和“重用服务器连接”，我猜这两个选项默认都是出于性能原因而开启的。我之前描述的正常工作/不正常工作的情况可以通过切换“重用客户端连接”来重现，而无需完全关闭 Fiddler。
通过将我的会话的连接模式与 Win 7 客户端与 Apache 之间的会话进行比较，发现不同之处在于我的 WebDAV 服务器总是断开连接，尤其是在返回 400 系列 HTTP 状态代码时，例如 401 Unauthorized。修复很简单，在 401 时保持连接处于活动状态可以立即解决问题。
我的同事是一位经验丰富的开发人员，他告诉我这是微软的一个古老漏洞，它已经存在了 12 年多，但他们从未修复过它。客户端启动 TCP 连接 C，然后发送纯 HTTP 请求，服务器将生成 401 响应以及“WWW-Authenicate”标头（包括摘要信息），并将其发送回客户端。此时，服务器可以选择保持连接或断开连接，无论“Connection”、“Keep-Alive”标头之前的内容如何。假设服务器决定断开连接，当 401 响应到达 win 7 客户端时，它将计算摘要身份验证所需的“Authorization”标头，但是，win 7 客户端坚持通过之前创建的连接 C 发送此标头，如果 C 断开，它将启动新连接 C'，发送不带“Authorization”标头的纯请求。此时，您应该能够预测接下来会发生什么，并解释为什么存在多重登录问题。
总结上述过程，Win 7 客户端仅在两种情况下发送“授权”标头：1. 在您提交凭据之后，即第一次创建“授权”标头时；2. 该连接与发送原始纯文本请求并得到 401 响应的连接相同。
HTTP 是无状态协议，客户端和服务器都不应该依赖任何状态，例如连接状态。一个强大的服务器（例如启用了 WebDAV 模块的 Apache）或一个强大的客户端（例如 Cadaver）能够应对一个僵硬的客户端（例如 win 7 客户端）或一个僵硬的服务器（例如我的服务器）。
带有摘要的 WebDAV 很难正确使用，到目前为止我只看到两台服务器正确使用，一个是流行的 Apache DAV 模块，另一个是修复此错误后的我的服务器。
Win 7 WebDAV 支持确实很糟糕。您的客户还有很多其他选择。Cadaver 是 Linux/Unix 平台上出色的开源 WebDAV 客户端，Mac 内置了 WebDAV 支持，第三方客户端（如 Cyber Duck、BitKinex 等）都是不错的选择。但是，如果您的大部分客户仍然依赖 Windows 平台，因此 Win7 微型重定向器仍然是他们访问 WebDAV 服务器的最便捷方式，您可能仍需要让它为客户工作。以下是摘要式身份验证不起作用的其他一些可能原因。
- 您的身份验证逻辑实施错误，因此它甚至不会接受正确的凭据
- DAV 响应主体使用默认命名空间，有关更多详细信息，请参阅以下链接： http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-namespace-handling https://issues.apache.org/bugzilla/show_bug.cgi?id=49428
- 如果您正在发送“Authentication-Info”标头，请确保它正常工作 如果 > 全部发送“Authentication-Info”标头，请确保它正常工作
如果以上方法都不能帮到你，以下是我在寻找根本原因时发现的一些有用的方法：1. 使用 Fiddler、ngrep 来捕获和研究流量 2. 使用开源客户端和服务器作为基础参考。通过阅读代码，你可以了解流程的机制；代码经过充分测试并且可靠 3. 扩展你的视野。如果 HTTP 通信不起作用，原因可能是流量（内容）、超时（时间）、连接（上下文）等。 4. 记住一个老事实：HTTP 是无状态的。不应根据任何添加的状态做出任何假设 5. 仔细阅读 RFC，不要犹豫，在线提问
总而言之，摘要式身份验证是一种比基本身份验证更强大的方案。就当今的安全技术而言，基本身份验证实际上没有提供任何保护，而摘要式身份验证本质上容易受到中间人攻击。请仔细考虑您在哪种安全环境中使用它们。
答案4
BitKinex 是我发现的唯一一款可以在 Windows 7 上将 webdav 转换为自签名证书的程序。我对 Cyberduck 抱有希望，但发现它有同样的问题，需要输入两次密码后就死机了。显然，BitKinex 的人们发现了自签名的 win7 webdav 的一些深层秘密，这些秘密只向秘密社团的某些成员透露。哈哈，BitKinex 做得很棒，有调度程序和一切。