在IIS中我得到了：
http://myserver/myapplication
http://myserver/reports
报告应用程序实际上是使用Windows身份验证的报告服务。 myapplication是一个使用表单身份验证的asp.net应用程序。
服务器位于公司域之外。如果我首先访问报告并在提示时键入用户和密码（在服务器上创建的本地凭据），我可以访问报告页面，没有问题。如果那时我直接进入我的应用程序的登录页面并尝试登录，登录页面刷新而不做任何事情。这总是发生在IE 6中。在IE 7中，它会间歇性地发生。在Firefox中不会发生，或者Fiddler在后台运行，似乎可以动态解决问题。
我使用wireshark查看发生了什么，并发现IE 6将从报告应用程序获取的Windows身份验证令牌发送到myapp。这是IE和Firefox之间的唯一区别。 IIS似乎吓坏了，只是将我的POST解释为登录页面作为GET并返回。
如果我将IIS身份验证添加到IIS中的myapplication，那么任何浏览器都能正常运行。
为什么会这样？ IE中的一个错误或我错过了什么？
答案 0 :(得分：13)
它有点像IE中的一个错误，并且是通过HTTP设计NTLM / Negotiate（又称集成）身份验证的错误。
NTLM / Negotiate是面向连接的身份验证协议，HTTP并非真正为其设计。因此，当您在服务器上为一个页面需要此身份验证机制时，IE通常会假定服务器上的其他页面具有相同的要求。
此外，出于性能和安全性原因，如果IE 期望对给定的POST请求进行Negotiate / NTLM质询，那么它将首先发送一个0字节的POST，期望服务器返回HTTP / 401挑战它将进行身份验证，然后正确发送POST正文。
然而，在你的情况下，不需要集成auth的文件夹获得0字节POST并说“Hrm，很奇怪，一个0字节的帖子。好的，HTTP / 200，这里的页面好像你曾经使用过GET“。
因为IE从未得到它所期望的401挑战，所以它实际上从未发送过POST主体。
（由于HTTP连接重用的工作方式，Fiddler可能会让您感到困惑。）
解决方法是确保如果您在主机上使用集成身份验证，请在任何地方使用它。