WebDAV アクセスには DIGEST 認証を使用しています。Windows クライアントが各要求を 2 回送信することがわかります。最初のリクエストにはヘッダーがありませんAuthorization(そして 401 レスポンスを取得します)。2 番目のリクエストにはAuthorizationヘッダーがあります (そして通常は正しいレスポンスを取得します)。
ユーザーはおそらくこれを見ることができませんが、Webdav アクセス全体が必要以上に遅くなります。
どういうわけかこの動作を回避することは可能ですか? Windowsにこれを行わないように説得する特別な応答があるでしょうか？AuthorizationDIGEST の代わりに BASIC を使用すると、問題なく動作します (ヘッダーが常に含まれている単一の要求のみを実行します)。
「チャレンジ/レスポンス」メソッドと呼ばれる、あなたが説明したメソッドは、WebDAVの意図された動作であると思います。少なくともそれは仕様によるものです。認証ヘッダーのない最初のリクエストが必要です。WebDAV からの応答には、次の要求を検証するためのノンスが含まれており、リプレイ攻撃などを回避するのに役立ちます。
要するに、この動作を避けることはできませんし、避けるべきではありません。
これを行っている Windows 以外のクライアントについては、最初のチャレンジ/レスポンス コールの後、なんらかの方法でナンスをキャッシュして再利用している可能性があります。これは確かに仕様で許可されています。ナンスは使い捨てのアイテムであると想定されていますが、仕様では、WebDAV サーバーが複数のリクエスト間でナンスを短命にすることを許可しています。Windows 以外のクライアントが WebDAV サーバーを認識し、それに応じて動作する可能性がありますが、Windows クライアントはそうではありません。
その場合、ノンスをキャッシュするクライアントを見つけるようにユーザーに依頼する以外に回避策を知りません。残念ながら、そのようなクライアントを見つけるお手伝いはできません。私の Google-fu はその点で失敗しました。
「事前認証」と呼ばれるものを調査することもできます。事前認証とは、最初の匿名リクエストを送信するのではなく、認証ヘッダーを含む最初のリクエストを送信することです。
通常、認証が必要かどうかは事前にわかっているため、アプリケーションと Web サービスはこれに適していますが、通常、Web サイトで認証が必要かどうかは事前にわかりません。
WebFolders/WebDAV は特殊なケースですが、やはりよくわかりません。
事前認証の問題は、必ずしも信頼していないサイトに情報を送信する可能性があることです。基本認証は王国への鍵 (プレーンテキストのユーザー/パスワード) を提供しますが、ネゴシエート、NTLM、およびダイジェストはそれほど悪くありません。
Web サービスの .Net での事前認証については、こちらを参照してください。これを使用して、最初の 401 を正常に排除しました。
Windows WebFolderクライアントで苦労している場合は、 greenbytesWebDavサイトでホストされているこの問題リストを確認することをお勧めします。リストに含まれていないVista固有の詳細に気付いた場合は、編集者にメモを送信してください。
安全性の低いセットアップを許可してもかまわない場合の回避策は、PROPFIND 要求をリストする匿名のディレクトリ階層を許可し、その他すべてを認証することです。http://blog.klinsight.com/2013/02/windows-webdav-double-authentication.htmlを参照してください- (私は自分の仕事のためにその投稿を書きました)。時間の節約は重要です。