从响应如果缓存克星不匹配内容prevent包 [英] Prevent bundle from responding if cache buster doesn't match content

查看:163
本文介绍了从响应如果缓存克星不匹配内容prevent包的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用的是捆绑和微小跨服务器场,那里是一个交叉的新旧服务器的时期。

I'm using Bundling and Minification across a server farm where there is a cross-over period of old and new servers.

我的问题是,旧的服务器缓存新的软件包缓存克星URL的内容。

The issue I have is that the old servers are caching the content of the new bundle cache buster URL.

例如在 HTML被缓存在捆绑网址:

For example the new HTML is cached with the new bundle URL:

<script src="/bundle.css?v=RBgbF6A6cUEuJSPaiaHhywGqT7eH1aP8JvAYFgKh"></script>

这然后作出一个服务器,尚未更新用新的CSS code,这对当时缓存的请求。

This then makes a request to an old server which hasn't yet been updated with the new CSS code and this then cached.

束URL任何后续调用,然后将返回旧的code。

Any subsequent calls to the new bundle URL will then return the old code.

因此​​有检查包的内容散列缓存克星相匹配的一种方式?如果它不抛出例如404。

Therefore is there a way of checking that the content of the bundle matches the hashed cache buster? And if it doesn't throw a 404 for example.

使用我的例子中,当请求追溯到旧服务器的包上面它会检查该包的内容,生成内容哈希和比较这对查询字符串。

Using my example above when the request goes back to the old server for the bundle it would check the contents of the bundle, generate a content hash and compare this to the querystring.

在这种情况下缓存破坏者将不符合实际的内容哈希和404将被返回。

In this instance the cache-buster wouldn't match the actual content hash and a 404 would be returned.

最终用户将达到一个服务器同捆请求和正确的内容将被缓存。

Eventually a user would hit a new server with the bundle request and the correct content would be cached.

推荐答案

我们必将很快遇到了同样的问题自己,但我们一直坚持只有2更新域(分成两半的服务器,这样,有没有多个版本同时运行)。

We're bound to encounter the same issue ourselves soon, but we've been sticking to only 2 update domains (split the servers in half so that there's not more than one version running at a time).

据我看到它有4个可能的替代方案:

As far as I see it there are 4 possible alternatives:


  1. 让您的静态内容总是指向一个最新的服务器。这可以通过IP地址或通过使用您知道已经更新(如果有被首先更新服务器)的URL来完成(取决于您的配置)。

  2. 配置负载平衡器,使来自同一IP地址的请求结束了在同一系统上(如果你的静态内容从您的应用程序服务器提供)。如果不能在负载均衡水平可以做到,那么你可以进一步做它通过为不同的环境配置不同的IP地址,然后交换左右将其DNS记录。

  3. 在ASP.NET中实现一个处理程序监听CSS文件,并检查该包的哈希值是否是它预计。你可能会需要一个单独的对象中存储这些时,他们当你的应用程序加载生成的。那么这可以返回404,301(让他们重试)或返回旧版本,但指示它不缓存的结果。请注意,HttpPipelining你可能不会打一个不同的服务器,这样一个重定向可能不会帮助。

  4. 有一个,而你正在做一个改变你所有的缓存清除的URL是当前的日期部署设置配置标记。这将有效地禁用所有缓存,直到你的部署完毕,这意味着交付的任何错误的资产不会被保留。

这是你实际看到了问题,或者是假设性的?除非你的网站是非常高的流量,你的部署走好几分钟的时间它不是你可能会看到的东西。你要警惕因为有时返回404错误的样式也比没有好样式的。

Is this a problem you're actually seeing, or is it hypothetical? Unless your site is very high traffic and your deploys take a good few minutes it's not something you're likely to see. You'll want to be wary of returning 404s as sometimes the wrong stylesheet is better than no stylesheet.

这篇关于从响应如果缓存克星不匹配内容prevent包的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆