ASP.NET网站制作之再次揭发text/vnd.wap.wml引发的ASP.NET OutputCache Bug及办理办法仓酷云 ...

你所列的那些其实差不多都可以称为应用服务器(servlet应该说是一种语言更合适)net网页编程是开放的，相同的工具就会有很多公司在做，加上net网页编程已经发展了很多年了，因此这些工具就很多了。他们很多都是类似的。在前一篇文章“一个陪伴ASP.NET从1.0到4.0的OutputCacheBug”中，揭发了ASP.NETOutputCache的一个扫瞄器缓存的Bug。
在这篇文章中，我们将揭发ASP.NETOutputCache的另外一个Bug，这个Bug在客岁2月份的时分揭发过一次，可是事先揭发不敷完全，办理办法也不敷完善。这里再揭发一次。
背景先容
为懂得决非电信誉户会见博客园的网速成绩（特别是南方网通用户），我们筹办接纳CDN减速。要让CDN减速发扬感化，就要创建无效的页面缓存机制（OutputCacheLocation要设置为"Any"）。为懂得决这个实践中的使用成绩，必需要好好研讨ASP.NETOutputCache，以是才会揭发它的Bug。
主要提醒
假如你在ASP.NET使用程序（非ASP.NETMVC）中利用了OutputCache，必定要存眷这个Bug，必定要下手往办理它！
成绩征象

登录/注册后可看大图

假如你见过下面的身影，你就已经与这个Bug相遇过大概相逢过。（不经意的相遇大概相逢，大概只是擦肩而过，大概就是天长日久；不要等候偶尔，但也不要无视偶尔。）
现在我们与它相遇时，它“忽隐忽现”（呈现在未几见的特定的情形下），让人“颠三倒四”（面临这个成绩无从动手）。
扫瞄器为何会给出这个窗口呢？
只是由于Web服务器和扫瞄器说了一句话（ResponseHeaders）："Content-Type:text/vnd.wap.wml;charset=utf-8"。为何要说如许的话？请看上面的分化。
成绩产生历程
1）当你在一个ASP.NET页面中增添了OutputCache设置，好比：

1. <%@OutputCacheDuration="300"VaryByParam="*"%>

复制代码

2）然后，在缓存没有创建（大概已过时）时，一部手机经由过程扫瞄器以WAP体例第一个哀求了这个页面（Requestheaders中包括"Accept:text/vnd.wap.wml"，如许的哀求大概经由过程代码举行摹拟，详见这里）。
3）接着，ASP.NET将这个哀求的呼应缓存了起来。这个操纵是在System.Web.Caching.OutputCacheModule.OnLeave中举行的，缓存内容来自System.Web.HttpResponse.GetSnapshot()，不但缓存了Responsebody，并且缓存了Responseheaders。
*【关头中央】在缓存Responseheaders时，ASP.NET依据"C:WindowsMicrosoft.NETFrameworkv4.0.30319ConfigBrowsersDefault.browser"中的设置举行了特别处置：

1. <defaultBrowserid="Wml"parentID="Default"><identification><headername="Accept"match="text/vnd.wap.wml|text/hdml"/><headername="Accept"nonMatch="application/xhtml+xml;profile|application/vnd.wap.xhtml+xml"/></identification><capabilities><capabilityname="preferredRenderingMime"value="text/vnd.wap.wml"/><capabilityname="preferredRenderingType"value="wml11"/></capabilities></defaultBrowser>

复制代码

因为倡议哀求的Accept为text/vnd.wap.wml，以是下面的恰好婚配，然后ASP.NET依据这里的设置，将Responseheaders中Content-Type的修正为"text/vnd.wap.wml;charset=utf-8"，并将之缓存。
4）接上去的在缓存周期内的哀求都是由这个缓存来欢迎（操纵在System.Web.Caching.OutputCacheModule.OnEnter中举行，终极由System.Web.HttpResponse.UseSnapshot前往缓存内容），只需不是WAP体例的哀求，就会呈现下面图中的下载文件对话框。
在办理这个成绩时，我们试图捕获这个呼应，经由过程FireFox的Firebug,Chrome的Developertools,Fiddler都没捕获到，厥后才试了试IE9的Developertools，居然捕获到了（第一次享用到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:WindowsMicrosoft.NETFrameworkv4.0.30319ConfigBrowsers
  
• 将Default.browser文件复制到桌面（别的再复制一份到别的一个文件夹举行备份）
  
• 用你喜好的编纂翻开桌面上的Default.browser文件，找到<defaultBrowserid="Wml"parentID="Default">部分，正文大概删除以下设置并保留：
  

1. <capabilities><capabilityname="preferredRenderingMime"value="text/vnd.wap.wml"/><capabilityname="preferredRenderingType"value="wml11"/></capabilities>

复制代码

• 将修正过的Default.browser文件复制至"C:WindowsMicrosoft.NETFrameworkv4.0.30319ConfigBrowsers"，掩盖同名文件。
  
• 以办理员身份运转命令行，cd进进"C:WindowsMicrosoft.NETFrameworkv4.0.30319ConfigBrowsers"，运转命令"aspnet_regbrowsers&ndash;i"：
  
  
  登录/注册后可看大图
  
  
• 年夜功形成，然后就能够恣意地举行OutputCache。
  

注：该办理办法基于之前的履历——ASP.NET4中不要信任Request.Browser.Cookies，Form考证要用UseCookies，假如事先不写博客，找到这个办理办法就没这么简单了。
晓得了缘故原由，办理办法有多种，我们这里只列出我们将接纳的办理办法。
ASP.NETMVC呢？
在ASP.NETMVC中没有这个Bug，前一文章中提到的“扫瞄器缓存的Bug”在ASP.NETMVC中也不存在。
小结
1）为何ASP.NET有这些Bug而ASP.NETMVC没有？
我想个中一个主要的缘故原由就是ASP.NET的关闭，ASP.NETMVC的开放（开源）——有了源代码，开辟者发明成绩时能够更快地找到真实的缘故原由，然后反应给微软。即便微软不克不及当即办理成绩，最少我能够修正源代码本人办理成绩，有了这个前提，开辟者碰到成绩才乐意追要究底。否则，即便找到了成绩的缘故原由，因为不克不及修正源代码，只能看成绩心叹（好比，我之前碰到的EntityFramework成绩）。ASP.NETMVC的开放是它乐成的关头，EntityFramework是不是乐成也将取决于它是不是开放。
2）ASP.NETWebForms与ASP.NETMVC会并存吗？
之前我以为会并存，但如今ASP.NETWebForms的Bug微软本人都懒得往办理，你还信任会并存吗？
有时也搞不懂应该学那种；主要看你以后去的那个公司是使用哪种了。就像王千祥的课上说的：企业应用现在主要就三层（其实也差不多就是MVC）：表示层（主要使用html写的，很简单）、业务逻辑层（主要就是应用服务器的）。最后就是数据层（其实就是学习数据库）

但是目前在CGI中使用的最为广泛的是Perl语言。所以，狭义上所指的CGI程序一般都是指Perl程序，一般CGI程序的后缀都是.pl或者.cgi。

Servlet的形式和前面讲的CGI差不多，它是HTML代码和后台程序分开的。它们的启动原理也差不多，都是服务器接到客户端的请求后，进行应答。不同的是，CGI对每个客户请求都打开一个进程（Process）。

大哥拜托，Java在95年就出来了，微软垄断个妹啊，服务器市场微软完全是后后来者，当年都是Unix的市场，现在被WindowsServer和Linux抢下大片，包括数据库也一样。

对于中小项目来说.net技术是完全可以胜任，但为什么现在大型公司或网站都选择php或java呢？就是因为微软不够开放，没有提供从硬件到应用服务器再到业务应用的整套解决方案。

以上是语言本身的弱点，在功能方面ASP同样存在问题，第一是功能太弱，一些底层操作只能通过组件来完成，在这点上是远远比不上PHP/JSP，其次就是缺乏完善的纠错/调试功能，这点上ASP/PHP/JSP差不多。

对于中小项目来说.net技术是完全可以胜任，但为什么现在大型公司或网站都选择php或java呢？就是因为微软不够开放，没有提供从硬件到应用服务器再到业务应用的整套解决方案。

平台无关性是PHP的最大优点，但是在优点的背后，还是有一些小小的缺点的。如果在PHP中不使用ODBC，而用其自带的数据库函数（这样的效率要比使用ODBC高）来连接数据库的话，使用不同的数据库，PHP的函数名不能统一。这样，使得程序的移植变得有些麻烦。不过，作为目前应用最为广泛的一种后台语言，PHP的优点还是异常明显的。

主流网站开发语言之JSP:JSP和Servlet要放在一起讲，是因为它们都是Sun公司的J2EE（Java2platformEnterpriseEdition）应用体系中的一部分。

由于JSP/Servlet都是基于Java的，所以它们也有Java语言的最大优点——平台无关性，也就是所谓的“一次编写，随处运行（WORA–WriteOnce,RunAnywhere）”。除了这个优点，JSP/Servlet的效率以及安全性也是相当惊人的。

微软又推出ASP.NET。这不是ASP的简单升级，而是全新一代的动态网页实现系统，用于一台WEB服务器建立强大的应用程序。是微软发展的新体系结构.NET的一部分，是ASP和.NET技术的结合。

ASP在执行的时候，是由IIS调用程序引擎，解释执行嵌在HTML中的ASP代码，最终将结果和原来的HTML一同送往客户端。

主流网站开发语言之CGI:CGI就是公共网关接口(CommonGatewayInterface)的缩写。它是最早被用来建立动态网站的后台技术。这种技术可以使用各种语言来编写后台程序，例如C，C++，Java，Pascal等。