现在的位置: 首页 > Windows > Windows Server > 正文
【转】text/vnd.wap.wml引起的ASP.NET OutputCache Bug及解决方法
2013年11月22日 Windows Server ⁄ 共 3207字 【转】text/vnd.wap.wml引起的ASP.NET OutputCache Bug及解决方法已关闭评论 ⁄ 被围观 4,725 views+

背景介绍

为了解决非电信用户访问博客园的网速问题(尤其是北方网通用户),我们准备采用CDN加速。要让CDN加速发挥作用,就要建立有效的页面缓存机制(OutputCache Location要设置为"Any")。为了解决这个实际中的应用问题,必须要好好研究ASP.NET OutputCache,所以才会揭露它的Bug。

重要提示

如果你在ASP.NET应用程序(非ASP.NET MVC)中使用了OutputCache,一定要关注这个Bug,一定要动手去解决它!

问题现象

如果你见过上面的身影,你就曾经与这个Bug相遇过或者重逢过。(不经意的相遇或者重逢,也许只是擦肩而过,也许就是天长地久;不要期待偶然,但也不要忽视偶然。)

当初我们与它相遇时,它“忽隐忽现”(出现在不多见的特定的情况下),让人“神魂颠倒”(面对这个问题无从下手)。

浏览器为什么会给出这个窗口呢?

只是因为Web服务器和浏览器说了一句话(Response Headers):"Content-Type:text/vnd.wap.wml; charset=utf-8"。为什么要说这样的话?请看下面的分解。

问题发生过程

1)当你在一个ASP.NET页面中增加了OutputCache设置,比如:

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

2)然后,在缓存没有建立(或者已经过期)时,一部手机通过浏览器以WAP方式第一个请求了这个页面(Request headers中包含"Accept:text/vnd.wap.wml",这样的请求可能通过代码进行模拟,详见这里)。

3)接着,ASP.NET将这个请求的响应缓存了起来。这个操作是在System.Web.Caching.OutputCacheModule.OnLeave中进行的,缓存内容来自System.Web.HttpResponse.GetSnapshot(),不仅缓存了Response body,而且缓存了Response headers。

*【关键地方】在缓存Response headers时,ASP.NET根据"C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers\Default.browser"中的配置进行了特殊处理:

复制代码
<defaultBrowser id="Wml" parentID="Default">
<identification>
    <header name="Accept" match="text/vnd\.wap\.wml|text/hdml"/>
    <header name="Accept" nonMatch="application/xhtml\+xml; profile|application/vnd\.wap\.xhtml\+xml"/>
</identification>
<capabilities>
    <capability name="preferredRenderingMime"              value="text/vnd.wap.wml"/>
    <capability name="preferredRenderingType"              value="wml11"/>
</capabilities>
</defaultBrowser>
复制代码

由于发起请求的Accept为text/vnd.wap.wml,所以上面的正好匹配,然后ASP.NET根据这里的配置,将Response headers中Content-Type的修改为"text/vnd.wap.wml; charset=utf-8",并将之缓存。

4)接下来的在缓存周期内的请求都是由这个缓存来迎接(操作在System.Web.Caching.OutputCacheModule.OnEnter中进行,最终由System.Web.HttpResponse.UseSnapshot返回缓存内容),只要不是WAP方式的请求,就会出现上面图中的下载文件对话框。

在解决这个问题时,我们试图捕捉这个响应,通过FireFox的Firebug, Chrome的Developer tools, Fiddler都没捕捉到,后来才试了试IE9的Developer tools,竟然捕捉到了(第一次享受到IE9带来的惊喜)。见下图:

问题的原因就在这里,正确的Content-Type应该是"text/html; charset=utf-8",ASP.NET却对WAP请求进行了特殊对待,由Accept决定Content-Type(难道是“屁股决定脑袋”)。可能是WAP的应用场景需要这样的设计,但在设计时却没有考虑对OutputCache的影响。

(注:我们测试了,将客户端请求的Accept改为其他类型,比如text/plain,都不存在这个问题)

从前面描述的过程中,我们可以知道,解决问题要在第3步提到的Default.browser文件下手。

推荐解决方法

前提条件:当前Web服务器上没有WAP站点

优点:一处更改,对当前Web服务器上的所有站点都有效。

操作步骤:

  • 进入C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers
  • 将Default.browser文件复制到桌面(另外再复制一份到另外一个文件夹进行备份)
  • 用你喜欢的编辑打开桌面上的Default.browser文件,找到<defaultBrowser id="Wml" parentID="Default" >部分,注释或者删除以下配置并保存:
<capabilities>
    <capability name="preferredRenderingMime"              value="text/vnd.wap.wml"/>
    <capability name="preferredRenderingType"              value="wml11"/>
</capabilities>
  • 将修改过的Default.browser文件复制至"C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers",覆盖同名文件。
  • 以管理员身份运行命令行,cd进入"C:\Windows\Microsoft.NET\Framework\v4.0.30319",运行命令"aspnet_regbrowsers -i":
    201103061552361490
  • 大功造成,然后就可以尽情地进行OutputCache。

注:该解决方法基于之前的经验 —— ASP.NET4中不要相信Request.Browser.Cookies,Form验证要用UseCookies,如果当时不写博客,找到这个解决方法就没这么容易了。

知道了原因,解决方法有多种,我们这里只列出我们将采用的解决方法。

ASP.NET MVC呢?

在ASP.NET MVC中没有这个Bug,前一文章中提到的“浏览器缓存的Bug”在ASP.NET MVC中也不存在。

小结

1)为什么ASP.NET有这些Bug而ASP.NET MVC没有?

我想其中一个重要的原因就是ASP.NET的封闭,ASP.NET MVC的开放(开源)—— 有了源代码,开发者发现问题时可以更快地找到真正的原因,然后反馈给微软。即使微软不能立即解决问题,至少我可以修改源代码自己解决问题,有了这个条件,开发者遇到问题才愿意追要究底。不然,即使找到了问题的原因,由于不能修改源代码,只能望问题心叹(比如,我之前遇到的Entity Framework问题)。ASP.NET MVC的开放是它成功的关键,Entity Framework是否成功也将取决于它是否开放。

2)ASP.NET WebForms与ASP.NET MVC会并存吗?

以前我觉得会并存,但现在ASP.NET WebForms的Bug微软自己都懒得去解决,你还相信会并存吗?

抱歉!评论已关闭.

×