加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程开发 > asp.Net > 正文

asp.net-mvc – 为什么Chrome在这两种情况下使用不同的客户端缓

发布时间:2020-12-16 07:45:31 所属栏目:asp.Net 来源:网络整理
导读:我正在使用 HTML5开发一个小型的单页应用程序.一个功能是显示嵌入在页面中的PDF文档,可以从列表中选择哪些文档. 我正在尝试制作Chrome(首先,然后是所有其他现代浏览器)使用本地客户端缓存来完成对PDF文档的简单GET请求,而无需通过服务器(当然不是第一次).我
我正在使用 HTML5开发一个小型的单页应用程序.一个功能是显示嵌入在页面中的PDF文档,可以从列表中选择哪些文档.

我正在尝试制作Chrome(首先,然后是所有其他现代浏览器)使用本地客户端缓存来完成对PDF文档的简单GET请求,而无需通过服务器(当然不是第一次).我通过在< object>上设置“data”属性来请求PDF文件. HTML中的元素.

我找到了working example for XMLHttpRequest(不是< object>).如果您使用Chrome的开发人员工具(网络标签),您可以看到第一个请求发送到服务器,并导致对这些标头的响应:

Cache-Control:public,Public
Content-Encoding:gzip
Content-Length:130
Content-Type:text/plain; charset=utf-8
Date:Tue,03 Jul 2012 20:34:15 GMT
Expires:Tue,03 Jul 2012 20:35:15 GMT
Last-Modified:Tue,03 Jul 2012 20:34:15 GMT
Server:Microsoft-IIS/7.5
Vary:Accept-Encoding

第二个请求是从本地缓存提供的,没有任何服务器往返,这就是我想要的.

回到我自己的应用程序,然后我使用ASP-NET MVC 4并设置

[OutputCache(Duration=60)]

在我的控制器上.对此控制器的第一个请求 – 使用URL http:// localhost:63035 /?doi = 10.1155 / 2007/98732会产生以下标头:

Cache-Control:public,max-age=60,s-maxage=0
Content-Length:238727
Content-Type:application/pdf
Date:Tue,03 Jul 2012 20:45:08 GMT
Expires:Tue,03 Jul 2012 20:46:06 GMT
Last-Modified:Tue,03 Jul 2012 20:45:06 GMT
Server:Microsoft-IIS/8.0
Vary:*

第二个请求导致另一个到服务器的往返,响应更快(建议服务器端缓存?)但返回200 OK和这些标头:

Cache-Control:public,max-age=53,03 Jul 2012 20:45:13 GMT
Expires:Tue,03 Jul 2012 20:45:06 GMT
Server:Microsoft-IIS/8.0
Vary:*

对同一URL的第三个请求导致另一个往返和带有这些标头的304响应:

Cache-Control:public,max-age=33,s-maxage=0
Date:Tue,03 Jul 2012 20:45:33 GMT
Expires:Tue,03 Jul 2012 20:45:06 GMT
Server:Microsoft-IIS/8.0
Vary:*

我的问题是,我应该如何设置OutputCache属性以获得所需的行为(即在初始请求的X秒内从客户端缓存中填写的PDF请求)?

或者,当我通过在< object>上设置“data”属性来显示PDF时,我做得不对.元件?

解决方法

客户永远不会有义务缓存.每个浏览器都可以自由使用它自己的启发式来决定是否值得缓存一个对象.毕竟,任何缓存的使用都与缓存的其他用途“竞争”.

缓存不是为了保证快速响应;平均而言,它旨在增加经常使用的不会改变的资源已经存在的可能性.你想要做的,不是什么缓存旨在帮助.

根据您报告的结果,您在2012年使用的Chrome版本认为缓存一个将在60秒后过期的对象毫无意义,并且只被要求过一次.所以它在使用之后扔掉了第一个副本.然后你第二次问了,它开始给这个URL更优先 – 它必须记住最近的URL,并观察到这是第二个请求 – 它将副本保存在缓存中,但是当第三个请求来了,要求服务器验证它仍然有效(大概是因为到期时间只有几秒钟).服务器说“304 – 未修改 – 使用你缓存的副本”.它没有再发送pdf.

恕我直言,这是一个合理的缓存行为,对于即将到期的对象.

如果您希望增加PDF更长时间停留的可能性,请提供更晚的到期时间,但要说它必须与服务器核实是否仍然有效.

如果使用HTTP Cache-Control标头,则可能是:private,max-age:3600,must-revalidate.有了这个,您应该看到服务器的往返,只要页面有效,就会给出304响应.这应该是一个快速响应,因为没有数据被发回 – 使用浏览器的缓存版本.

private是可选的 – 与此缓存行为无关 – 我假设这个易失性PDF是什么,它只对给定用户有意义和/或在一些共享位置不应该长时间闲逛.

如果你真的需要不与服务器交谈的性能,那么考虑编写javascript来隐藏/显示持有该PDF的DOM元素,而不是丢弃它,并且需要再次询问它.

您的页面的javascript代码是“理解”您真正希望PDF保留的唯一地方,即使您当前没有向用户显示它.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读