Question

我有一个非常奇怪的问题 - IIS 6上的ASP.NET 3.5 Webforms应用程序。

效果是用户连接到我们的站点，并获得一个ASP.NET会话，输入一些数据，突然，他输入的所有数据（并存储在会话中）都消失了。

错误日志告诉我们，由于一些奇怪的原因，他只是在我们的应用程序中工作的新会话。

从IIS日志中，我们看到来自用户浏览器切换的用户代理从单个ASP.NET请求中，从MSIE+7.0到MSIE+8.0。 .. 怎么可能？

摘自日志：

07:06:38   GET /SomePage.aspx  80 - x.x.x.139   Mozilla/4.0+ (compatible;+MSIE+7.0;+Windows+NT+5.1)   401 
07:06:38   GET /SomePage.aspx  80 DOMAIN\USERNAME  x.x.x.139  Mozilla/4.0+ (compatible;+MSIE+7.0;+Windows+NT+5.1)   200

07:06:39   GET /javascript/somefile.js 80   DOMAIN\USERNAME x.x.x.139   Mozilla/4.0+ (compatible;+MSIE+8.0;+Windows+NT+5.1)  200 
(lots more requests for .css, .js, .gif, .jpg - all with MSIE+8.0 ....)

似乎.aspx页面的两个请求是以MSIE+7.0模式完成的，而对CSS和JS文件以及GIF和JPG图形的任何后续请求都会报告MSIE+8.0。 ..... WTF？！？！？

不确定这是否真的是突然丢失ASP.NET会话的根本原因 - 但是用户代理切换本身让我们感到头疼......任何想法？

如果这种行为不是那些“失去的会话”的根本原因 - 任何想法/引导可能是什么原因？到目前为止，我还没有能够从Bing，Google或任何其他来源中挖掘出任何过于有用的内容......

更新：我读到in this forum thread用户代理在第一个GET（提取.aspx页面）和后续{{对GET，.css的请求可能会导致会话丢失（但这是一个PHP环境）。任何人都可以确认这是否也适用于ASP.NET？（或表明此陈述不属实）

如果确实如此 - 有没有办法告诉ASP.NET 不启动新的sesssion只是因为用户代理字符串与之前的请求不匹配？

Answer 1

你在这里描述的确听起来确实很奇怪。

没有看到它在行动中很难确定发生了什么，但是（不包括UA欺骗）我只能想到一件可以在这里工作的东西：兼容模式。

我不知道IE为不同的请求类型提供不同的UA字符串，即使在兼容模式下也是如此，但我想这是可能的。

但无论如何，我的建议是通过向页面添加X-UA-Compatible元标题来防止IE完全使用兼容模式。这样的事情应该这样做：

<meta http-equiv="x-ua-compatible" content="IE=edge">

将其添加到HTML代码的<head>部分顶部附近。

这应该迫使IE使用它最好的页面渲染引擎。没有更多的兼容模式。因此，如果这是您神秘变化的UA字符串的原因，它应该解决这个问题。

（当然，如果用户有一个欺骗UA字符串的浏览器，所有的赌注都会关闭。但即使这样，他们想要在会话中间做这件事似乎很奇怪）

用户代理在请求中间切换？

1 个答案: