codecamp

Django4.0 缓存框架-下游缓存

到目前为止,本文档的重点是缓存您自己的数据。 但是另一种类型的缓存也与 Web 开发相关:由“下游”缓存执行的缓存。 这些系统甚至在请求到达您的网站之前就为用户缓存页面。

下面是一些下游缓存的例子:

  • 使用 HTTP 时,您的 ISP 可能会缓存某些页面,因此如果您从 http://example.com/ 请求页面,您的 ISP 将向您发送该页面,而无需直接访问 example.com。 example.com 的维护者不知道这种缓存; ISP 位于 example.com 和您的 Web 浏览器之间,透明地处理所有缓存。 这种缓存在 HTTPS 下是不可能的,因为它会构成中间人攻击。
  • 您的 Django 网站可能会在一个代理缓存的后面,例如Squid 网页代理缓存,为了性能而缓存页面。在这种情况下,每个请求首先由代理来处理,只有在需要时才将其传递给应用程序。
  • 您的网络浏览器也会缓存页面。 如果网页发送了适当的标头,您的浏览器将使用本地缓存副本来处理对该页面的后续请求,甚至无需再次联系该网页以查看它是否已更改。

下游缓存是一个很好的效率提升,但它存在一个危险:许多网页的内容基于身份验证和许多其他变量而有所不同,并且缓存系统盲目地仅基于 URL 保存页面可能会将不正确或敏感的数据暴露给后续这些页面的访问者。

例如,如果您使用网络电子邮件系统,那么收件箱页面的内容取决于登录的用户。如果 ISP 盲目缓存您的站点,那么通过该 ISP 登录的第一个用户将拥有他们的用户 - 为该站点的后续访问者缓存的特定收件箱页面。

幸运的是,HTTP 为这个问题提供了解决方案。存在许多 HTTP 报头以指示下游缓存根据指定的变量来区分它们的缓存内容,并且告诉缓存机制不缓存特定的页面。


Django4.0 缓存框架-异步支持
Django4.0 缓存框架-使用Vary标头
温馨提示
下载编程狮App,免费阅读超1000+编程语言教程
取消
确定
目录

Django4.0 模型和数据库

Django4.0 处理HTTP请求

关闭

MIP.setData({ 'pageTheme' : getCookie('pageTheme') || {'day':true, 'night':false}, 'pageFontSize' : getCookie('pageFontSize') || 20 }); MIP.watch('pageTheme', function(newValue){ setCookie('pageTheme', JSON.stringify(newValue)) }); MIP.watch('pageFontSize', function(newValue){ setCookie('pageFontSize', newValue) }); function setCookie(name, value){ var days = 1; var exp = new Date(); exp.setTime(exp.getTime() + days*24*60*60*1000); document.cookie = name + '=' + value + ';expires=' + exp.toUTCString(); } function getCookie(name){ var reg = new RegExp('(^| )' + name + '=([^;]*)(;|$)'); return document.cookie.match(reg) ? JSON.parse(document.cookie.match(reg)[2]) : null; }