浏览器历史记录清除后网站无法正常工作

Question

我有一个旧的ASP.NET Intranet应用程序，其中表单登录页面显示异常行为。如果任何版本的IE在提交到登录页面时都有清除历史记录（历史记录，而不是cookie），则执行空白回发并保留在登录页面上。

如果他们刷新页面或被重定向到登录页面，试图直接访问另一个页面，那么他们就会毫无困难地登录。

我已将此应用程序的其他副本发布到同一个IIS服务器，但它们最初没有表现出这种行为，但是经过一段时间后，它们开始以相同的方式运行。重新发布到同一个实例不会“解决”发布到新站点的问题，也不会删除旧应用程序然后发布到同一名称。

我不知道从哪里可以去，所以任何帮助都会受到赞赏。

对我而言，这些是我所做的主要观察：

1. 这只影响我们的生产服务器。发布到另外两台服务器的相同代码不会出现此缺陷。这段代码直到最近一直有效。
2. 我将带有Response.Redirect的按钮点击代码替换为Google。如果按钮行为不正确，则不会触发此重定向。这向我表明按钮代码没有被执行。页面重新加载/刷新后，它会正确重定向，因为按钮代码现在正在触发。
3. 当相同的代码以不同的名称发布到此IIS服务器时，它不会在几个小时内出现此缺陷。几个小时后可能会发生什么情况导致这种行为改变？重新发布到同一个IIS站点并不能解决几个小时的问题，例如发布到新的IIS站点。

我已从此帖子中删除了按钮代码，因为在我看来，这是一个红色的鲱鱼，因为代码似乎根本没有被执行。

这是网站工作时网络工具中的Cookie

从站点工作到不工作的不同之处在于Form1键被标记为已发送而未被接收。

我还注意到一些新的东西，当网站不工作时，favicon显示为（已中止）。我现在认为请求已完全中止，因为我已经覆盖了页面的OnInit，并且当网站不工作时我输入的代码没有被执行。

今天我的工作向微软公开了一张票，以帮助解决这个问题，并且他们说这是一个“头脑清醒。”

Answer 1

我不同意Nick的想法，因为你的断言，代码中存在问题：

  

这只影响我们的生产服务器。发布到另外两台服务器的相同代码不会出现此缺陷。这段代码直到最近一直有效。

这表明服务器之间存在差异，它们的配置方式或部署的代码阻止了它的运行。由于这是一个表单身份验证问题，我想起了在IE10中搞乱表单身份验证的错误 - 请参阅IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)

您的服务器是否相同？运行相同的操作系统，.NET版本，修补程序，修补程序等？

Answer 2

微软挽救了这一天。

他们告诉我们，IE的旧版本将在IIS的根文件夹中查找favicon而不是应用程序路径，无论您指向哪里查看它。我们发现根文件夹的身份验证设置仅设置为Windows身份验证。无论出于何种原因，这导致表单身份验证被中止，直到我们将Allow Anonymous添加到根文件夹。