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

我这里有一个非常奇怪的问题-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或任何其他来源找到任何非常有用的东西

更新：我了解到，用户代理在第一个

GET

（获取

.aspx

页面）和随后的

GET

请求

.css

，

.js

之间存在差异，这可能会导致会话丢失（不过这是一个PHP环境）。有人能确认这是否也适用于ASP.NET吗？（或表明该陈述不真实）

---

如果真是这样的话-有没有办法告诉ASP.NET不要因为用户代理字符串与以前的请求不匹配而启动新会话？

您在这里描述的内容听起来确实很奇怪

如果没有看到它的实际应用，很难确定到底发生了什么，但是（不包括UA欺骗），我能想到的只有一件事可能在这里起作用：兼容性模式

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

但在任何情况下，我的建议都是通过在页面中添加

X-UA-Compatible

meta标题来阻止IE使用兼容模式。像这样的东西应该可以做到：

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

将其添加到HTML代码的

部分的顶部附近

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

---

---

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

在PROC还是在Pro会话中？如果您的应用程序池被回收，则可能会发生这种情况。如果用户在兼容模式下运行IE8，则在请求页面时会将用户代理作为IE7发送@努内斯帕斯卡尔：这是在过程中-是的，应用程序池回收会导致这一点-但在一两秒钟内？对于一个完整的应用程序池回收来说似乎有点太快了…@nunesspascal：是的，同意-但是我不会看到所有

GET

请求所有资源的

MSIE+7.0

？为什么

MSIE+7.0

用于

.aspx

页面，然后

MSIE+8.0

用于其他所有内容？虽然我无法回答您的问题，但值得尝试将会话排除在进程之外。将消除对AppPool回收或IIS重置的任何疑问。