|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
net网页编程的设计机制:首先产生一个中间码,第二部编译为本地(机器)码。这个机制有很大的缺点。我们先来一睹这个Bug的风度!
在一个.aspx文件中增添OutputCache设置,代码以下:- <%@OutputCacheDuration="300"VaryByParam="*"%>
复制代码 下面的设置暗示:缓存5分钟,依据分歧的查询字符串更新缓存。Location利用的是默许值Any,也就是能够在扫瞄器、代办署理服务器、Web服务器三个中央举行缓存,在ResponseHeaders中的表现就是Cache-Control:public,max-age=300。(假如你要用CDN减速,Cache-Control就要用public)。
然后,我们在Firefox扫瞄器中会见这个页面,并翻开Firebug,见下图:
第一次会见,前往形态码为"200OK",一般。这里ResponseHeaders中的Vary:Accept-Encoding是由于IIS启用“静态内容紧缩”发生的,假如不启用,就不会呈现。
这时候缓存应当被创建起来了,我们按F5革新一下扫瞄器,看一下了局,见下图:
第二次会见,前往形态码为"304NotModified",扫瞄器缓存失效,这也是我们希冀的。
可是,请注重一下上图中的Vary:*,它会让扫瞄器的缓存生效,我们再按一下F5考证一下。
公然,扫瞄器缓存生效,前往形态码变回了200OK。缓存工夫有5分钟呢,第三次就生效了,如许的了局明显不是我们希冀的。
下面的测试是在Web服务器上IIS启用静态内容紧缩(dynamiccontentcompression)的情形下举行的,假如封闭静态内容紧缩,每次哀求前往都是200OK,Vary都是星号。也就是说扫瞄器巡游缓存基本没起感化。
Bug浏览终了,我们举行第二个测试。
将OutputCache的VaryByParam属性值设置为none:- <%@OutputCacheDuration="600"VaryByParam="none"%>
复制代码 测试了局显现,扫瞄器第一次哀求以后,接上去在缓存工夫内,服务器的呼应都是"304NotModified",这才是我们想要的效果。
可是,在实践使用中,我们利用VaryByParam="none"很少,用的更多的是为VaryByParam指定对应的值。
以是这个Bug影响很年夜,增添了服务器包袱,华侈了带宽。
Bug相干信息
在微软的官方文档ASP.NET4BreakingChanges中专门提到了这个bug——"OutputCachingChangestoVary*HTTPHeader":InASP.NET1.0,abugcausedcachedpagesthatspecifiedLocation="ServerAndClient"asanoutput–cachesettingtoemitaVary:*HTTPheaderintheresponse.Thishadtheeffectoftellingclientbrowserstonevercachethepagelocally.
InASP.NET1.1,theSystem.Web.HttpCachePolicy.SetOmitVaryStarmethodwasadded,whichyoucouldcalltosuppresstheVary:*header.ThismethodwaschosenbecausechangingtheemittedHTTPheaderwasconsideredapotentiallybreakingchangeatthetime.However,developershavebeenconfusedbythebehaviorinASP.NET,andbugreportssuggestthatdevelopersareunawareoftheexistingSetOmitVaryStarbehavior.
InASP.NET4,thedecisionwasmadetofixtherootproblem.TheVary:*HTTPheaderisnolongeremittedfromresponsesthatspecifythefollowingdirective:
<%@OutputCacheLocation="ServerAndClient"%>
Asaresult,SetOmitVaryStarisnolongerneededinordertosuppresstheVary:*header.
InapplicationsthatspecifyLocation="ServerAndClient"inthe@OutputCachedirectiveonapage,youwillnowseethebehaviorimpliedbythenameoftheLocationattributesvalue–thatis,pageswillbecacheableinthebrowserwithoutrequiringthatyoucalltheSetOmitVaryStarmethod. 从下面的文档中我们能够晓得这个Bug的汗青:
在ASP.NET1.0时,假如在OutputCache中设置Location="ServerAndClient",在ASP.NET在呼应时会扫瞄器发送Vary:*HTTPheader。
在ASP.NET1.1时,微软针对这个Bug,供应一个专门的办法System.Web.HttpCachePolicy.SetOmitVaryStar(boolomit),经由过程SetOmitVaryStar(true)修正HTTPheader,往失落Vary:*。
在ASP.NET4时,微软慎重地公布从基本上办理了这个成绩。
并且,文档中提到这个bug只会呈现在Location="ServerAndClient"时。
但是,我用ASP.NET4的实测试情形是:不但Location="ServerAndClient"时的Bug没有办理,并且Location="Any"时也会呈现一样的Bug。
办理办法
办理办法很复杂,只需用ASP.NET1.1时期供应的System.Web.HttpCachePolicy.SetOmitVaryStar(boolomit)就可以办理成绩,只需在Page_Load中增加以下代码:- protectedvoidPage_Load(objectsender,EventArgse){Response.Cache.SetOmitVaryStar(true);}
复制代码 相干文档
ASP.NETcachingtestsfindabugwithVaryByParam
Howtocacheasp.netwebsiteforbetterperformance
MicrosoftConnect:TheServerAndClientparameterwiththeOutputCachepagedirectivedoesnotcacheontheclient,withoutcode
小结
小bug,办理办法也很复杂。可是,假如你不晓得这个bug,又会堕入微软的一个圈套(之条件到一个WCFClient的圈套),不知不觉中华侈了服务器资本与带宽。
微软那末有钱,有那末多天赋程序员,但是Bug也很难制止,可见开辟优异的软件是何等具有应战性的事情!
2003年中微软发布最新版本的ASP.netWebMatrix,对于我们喜欢用Asp.net来编程的朋友实在是个好消息,我也实实在在的将Asp.net更深入的研究了一下,以方便我以后更好的运用它,同时我也讲讲使用它的感受。 |
|