ASP.NET从1.0到4.0的输出缓存错误介绍

先来看看这个Bug吧！在中添加输出缓存设置。aspx文件，代码如下：复制的代码如下：% @ outputcacheduration=' 300 ' varybyparam=' * %以上设置的意思是：缓存5分钟，根据不同的查询字符串更新缓存。位置使用默认值“任意”，即可以缓存在浏览器、代理服务器和网络服务器中，响应头中的实施例是缓存控制：公共，最大年龄=300。(如果要使用CDN加速，缓存控制应该使用公共的)。然后，我们在Firefox浏览器中访问这个页面，打开Firebug，如下图：。

第一次就诊，返回的状态码是‘200 OK’，正常。这里，响应头中的Vary:Accept-Encoding是由IIS启用“动态内容压缩”引起的，如果未启用，它将不会出现。此时，应该建立缓存。让我们按F5刷新浏览器并查看结果。见下图：。

第二次访问，返回的状态代码是‘304未修改’，浏览器缓存生效，这也是我们所期待的。但是请注意上图中的Vary:*会使浏览器缓存失效。让我们再次单击F5进行验证。

果然浏览器缓存失败，返回状态码改回200 OK。缓存时间为5分钟，第三次失败。这个结果显然不是我们预期的。上述测试是在IIS在Web服务器上启用动态内容压缩时进行的。如果动态内容压缩被关闭，每个请求将返回200 OK，Vary将是一个星号。也就是说，浏览器游缓存根本不起作用。欣赏完Bug之后，让我们进行第二个测试。将OutputCache的VaryByParam属性值设置为none:复制代码如下：% @ output cacheduration=' 600 ' VaryByParam=' none ' %测试结果显示，浏览器第一次请求后，服务器在缓存时间内的响应为' 304 Not Modified '，这就是想要的效果。

但是，在实际应用中，我们使用VaryByParam='none '很少，用的更多的是为VaryByParam指定对应的值。所以这个病菌影响很大，增加了服务器负担，浪费了带宽臭虫。相关信息在微软的官方文档ASP .网四突破性变化中专门提到了这个错误——"输出缓存更改为可变* HTTP头":在ASP。NET 1.0中，一个错误导致将位置="服务器和客户端"指定为输出缓存设置的缓存页面在响应中发出可变：* HTTP头。这实际上是告诉客户端浏览器永远不要在本地缓存页面。在ASP.NET 1.1中，系统。添加了网络。httpachepolicy。setmitvarystar方法，您可以调用该方法来隐藏Vary:*头。之所以选择这个方法，是因为改变发出的超文本传送协议头在当时被认为是一个潜在的破坏性改变。然而，开发人员对ASP。网的行为感到困惑，错误报告表明开发人员不知道现有的SetOmitVaryStar行为。在ASP。NET 4中，决定解决根本问题。不再从指定以下方向的响应中发出变量：* HTTP头：% @输出缓存位置='服务器和客户端' %因此，不再需要SetOmitVaryStar来抑制变量：*头。在页面上的@ OutputCache指令中指定位置='服务器和客户端'的应用程序中，您现在将看到位置属性值的名称所暗示的行为，也就是说，页面将在浏览器中被缓存，而不需要调用SetOmitVaryStar方法。从上面的文档中我们可以知道这个病菌的历史：在ASP .NET 1.0时，如果在输出缓存中设置位置='服务器和客户端，在ASP .网在响应时会浏览器发送Vary:* HTTP头。在ASP.NET 1.1时，微软针对这个Bug，提供一个专门的方法系统网络。httpachepolicy。Setomitvarystar(bool省略),通过SetOmitVaryStar(真)修改超文本传送协议头，去掉Vary:*。在ASP .NET 4时，微软郑重地宣布从根本上解决了这个问题。而且，文档中提到这个病菌只会出现在位置='服务器和客户端'时。可是，我用ASP .NET 4的实测试情况是：不仅位置='服务器和客户端'时的病菌没有解决，而且位置='任何'时也会出现同样的Bug。解决方法解决方法很简单，只要用ASP .NET 1.1时代提供的系统网络。httpachepolicy。Setomitvarystar(bool省略)就能解决问题，只需在页面加载中添加如下代码：复制代码代码如下：受保护的无效页面_加载(对象发送者，事件参数e){ 0响应缓存。Setomitvarystar(真)；} 相关文档ASP。网缓存测试发现varybyparamshow有一个错误如何缓存ASP。网网站以获得更好的性能Microsoft Connect:带有输出缓存页面指令的服务器和客户端参数不在客户端缓存，没有代码小结小臭虫，解决方法也很简单。但是，如果你不知道这个臭虫，又会陷入微软的一个骗局（之前提到一个世界商会联合会客户的骗局),不知不觉中浪费了服务器资源与带宽。微软那么有钱，有那么多天才程序员，可是病菌也很难避免，可见开发优秀的软件是多么具有挑战性的工作！补充ASP .会员管理系统中不存在这个问题。