一个伴随ASP.NET从1.0到4.0的OutputCache Bug

我们先来一睹这个Bug的风采！

在一个.aspx文件中增加OutputCache设置，代码如下：

<%@ OutputCache Duration="300" VaryByParam="*"%>

上面的设置表示：缓存5分钟，根据不同的查询字符串更新缓存。Location使用的是默认值Any，也就是可以在浏览器、代理服务器、Web服务器三个地方进行缓存，在Response Headers中的体现就是Cache-Control:public, max-age=300。（如果你要用CDN加速，Cache-Control就要用public）。

然后，我们在Firefox浏览器中访问这个页面，并打开Firebug，见下图：

第一次访问，返回状态码为"200 OK"，正常。这里Response Headers中的Vary:Accept-Encoding是因为IIS启用“动态内容压缩”产生的，如果不启用，就不会出现。

这时缓存应该被建立起来了，我们按F5刷新一下浏览器，看一下结果，见下图：

第二次访问，返回状态码为"304 Not Modified"，浏览器缓存生效，这也是我们期望的。

但是，请注意一下上图中的Vary:*，它会让浏览器的缓存失效，我们再按一下F5验证一下。

果然，浏览器缓存失效，返回状态码变回了200 OK。缓存时间有5分钟呢，第三次就失效了，这样的结果显然不是我们期望的。

上面的测试是在Web服务器上IIS启用动态内容压缩（dynamic content compression）的情况下进行的，如果关闭动态内容压缩，每次请求返回都是200 OK，Vary都是星号。也就是说浏览器游览缓存根本没起作用。

Bug欣赏完毕，我们进行第二个测试。

将OutputCache的VaryByParam属性值设置为none：

<%@ OutputCache Duration="600" VaryByParam="none"%>

测试结果显示，浏览器第一次请求之后，接下来在缓存时间内，服务器的响应都是"304 Not Modified"，这才是我们想要的效果。

但是，在实际应用中，我们使用VaryByParam="none"很少，用的更多的是为VaryByParam指定对应的值。

所以这个Bug影响很大，增加了服务器负担，浪费了带宽。

Bug相关信息

在微软的官方文档ASP.NET 4 Breaking Changes中专门提到了这个bug —— "Output Caching Changes to Vary * HTTP Header":

补充：Web开发 , ASP.Net ,