我们对 WebDAV 访问使用 DIGEST 身份验证。我们观察到 Windows 客户端将每个请求发送两次。第一个请求没有Authorization 标头（并得到401 响应），第二个请求有Authorization 标头（通常得到正确的响应）。
虽然用户可能看不到这一点，但它会使整个 Webdav 访问速度变慢。
是否有可能以某种方式避免这种行为？也许一些特殊的回应会说服 Windows 不要这样做？当我们使用 BASIC 而不是 DIGEST 时，它可以正常工作（仅使用 Authorization 标头进行单个请求）
【问题讨论】：
我相信您描述的方法，称为“挑战/响应”方法，是 WebDAV 的预期行为。至少它是根据the specs。没有身份验证标头的第一个请求是必要的；来自 WebDAV 的响应包含一个 nonce 来验证下一个请求，帮助抵御例如重放攻击。
所以，底线：你不能，不应该尽量避免这种行为。
对于正在执行此操作的非 Windows 客户端...在初始质询/响应调用之后，它们可能会以某种方式缓存和重用 nonce。这在规范中当然是允许的——即使 nonce 应该是一次性项目，规范允许 WebDAV 服务器在多个请求中使 nonce 短暂。您的非 Windows 客户端可能能够识别您的 WebDAV 服务器并采取相应措施，但 Windows 客户端则不能。
在这种情况下，除了要求用户找到一个缓存 nonce 的客户端之外，我不知道有什么解决方法。不幸的是，我无法帮助您找到这样的客户。我的 Google-fu 在这方面失败了。
【讨论】：
您还可以研究称为“预身份验证”的东西。 Preauthentication 是发送带有身份验证标头的第一个请求，而不是发送初始匿名请求。
虽然应用程序和 Web 服务非常适合这种情况，因为您通常事先知道是否需要身份验证，但您通常不知道网站是否需要事先进行身份验证。
WebFolders/WebDAV 是一种特殊情况，但同样，您不确定。
预身份验证的问题在于，您可能会将信息发送到您不一定信任的网站。基本身份验证会泄露王国的密钥（纯文本中的用户/密码），但协商、NTLM 和摘要也不错。
您可以查看here 在 .Net 中为 Web 服务进行预身份验证，我已使用它成功消除了最初的 401。
【讨论】：
如果您在使用 Windows WebFolder 客户端时遇到困难，您可能需要查看托管在 greenbytes WebDav site 上的 this issues list。如果您发现列表中未包含任何 Vista 特定细节，请向编辑发送说明。
【讨论】：
如果您不介意允许不太安全的设置，一个解决方法是允许匿名目录层次结构列出 PROPFIND 请求并验证其他所有内容；见http://blog.klinsight.com/2013/02/windows-webdav-double-authentication.html - （我为我的工作写了那篇文章）。节省大量时间。
【讨论】：