强制刷新缓存的 CSS 数据 [英] Force refresh of cached CSS data

问题描述

是否可以强制浏览器刷新缓存的 CSS?

Is it possible force the browser to fresh the cached CSS?

这不像每个请求那么简单.我们有一个具有稳定 CSS 的站点.

This is not as simple as every request. We have a site that has had stable CSS for a while.

现在我们需要对 CSS 进行一些重大更新；但是，缓存了 CSS 的浏览器在几天内不会收到新的 CSS，从而导致呈现问题.

Now we need to make some major updates to the CSS; however, browsers that have cached the CSS will not receive the new CSS for a couple of days causing rendering issues.

有没有办法强制刷新 CSS 还是我们最好只选择版本特定的 CSS URL?

Is there a way to force refresh of the CSS or are we better just opting for version specific CSS URLs?

推荐答案

有几件事需要考虑，也有多种方法可以解决这个问题.首先，规范

There are several things to consider and a variety of ways to approach this. First, the spec

理想情况下，修改后的资源将在第一次被请求时无条件地获取，然后从本地缓存中检索，直到它在没有后续服务器交互的情况下过期.

Ideally, a modified resource will be unconditionally fetched the first time it is requested, and then retrieved from a local cache until it expires with no subsequent server interaction.

跟踪不同的排列可能有点令人困惑，因此我创建了下表.这些观察结果是通过从 Chrome 向 IIS 发出请求并观察开发者控制台中的响应/行为而生成的.

Keeping track of the different permutations can be a bit confusing, so I created the following table. These observations were generated by making requests from Chrome against IIS and observing the response/behavior in the developer console.

在所有情况下，新 URL 都会导致 HTTP 200.重要的是后续请求会发生什么.

In all cases, a new URL will result in HTTP 200. The important thing is what happens with subsequent requests.

+---------------------+--------------------+-------------------------+
|        Type         |   Cache Headers    |     Observed Result     |
+---------------------+--------------------+-------------------------+
| Static filename     | Expiration +1 Year | Taken from cache        |
| Static filename     | Expire immediately | Never caches            |
| Static filename     | None               | HTTP 304 (not modified) |
|                     |                    |                         |
| Static query string | Expiration +1 Year | HTTP 304 (not modified) |
| Static query string | Expire immediately | HTTP 304 (not modified) |
| Static query string | None               | HTTP 304 (not modified) |
|                     |                    |                         |
| Random query string | Expiration +1 Year | Never caches            |
| Random query string | Expire immediately | Never caches            |
| Random query string | None               | Never caches            |
+---------------------+--------------------+-------------------------+

但是，请记住浏览器和 Web 服务器并不总是按照我们期望的方式运行.一个著名的例子:2012 年移动 Safari 开始缓存 POST 请求.开发人员不满意.

However, remember that browsers and web servers don't always behave the way we expect. A famous example: in 2012 mobile Safari began caching POST requests. Developers weren't pleased.

^{ASP.Net MVC Razor 语法示例，但几乎适用于任何服务器处理语言.}

...因为一些应用程序传统上使用 GET 和 HEAD查询 URL(那些在 rel_path 部分包含?"的)来执行具有显着副作用的操作，缓存不得处理除非服务器提供明确的 URI 响应，否则响应为新鲜到期时间.这特别意味着来自 HTTP/1.0 的响应不应从缓存中获取此类 URI 的服务器.

...since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache.

在包含在 HTML 中的 CSS URL 末尾附加一个随机参数将强制执行一个新请求，并且服务器应该以 HTTP 200(不是 304，即使它没有被响应)修改).

Appending a random parameter to the end of the CSS URL included in your HTML will force a new request and the server should respond with HTTP 200 (not 304, even if it is hasn't been modified).

<link href="normalfile.css?random=@Environment.TickCount" />

当然，如果我们使用每个请求随机化查询字符串，这将完全破坏缓存.对于生产应用程序来说，这很少/从不理想.

Of course, if we randomize the query string with every request, this will defeat caching entirely. This is rarely/never desirable for a production application.

如果您只维护几个 URL，您可以手动修改它们以包含内部版本号或日期:

If you are only maintaining a few URLs, you might manually modify them to contain a build number or a date:

@{
    var assembly = Assembly.GetEntryAssembly();
    var name = assembly.GetName();
    var version = name.Version;
}

<link href="normalfile.css?build=@version.MinorRevision" />

这会在用户代理第一次遇到 URL 时产生新的请求，但后续的请求大多会返回 304.这仍然会导致发出请求，但至少不会提供整个文件.

This will cause a new request the first time the user agent encounters the URL, but subsequent requests will mostly return 304s. This still causes a request to be made, but at least the whole file isn't served.

更好的解决方案是创建一条新路径.只需稍加努力，这个过程就可以自动化，用版本号(或其他一些一致的标识符)重写路径.

A better solution is to create a new path. With a little effort, this process can be automated to rewrite the path with a version number (or some other consistent identifier).

这个answer 展示了一些适用于非 Microsoft 平台的简单而优雅的选项.

This answer shows a few simple and elegant options for non-Microsoft platforms.

Microsoft 开发人员可以使用 HTTP 模块拦截给定文件类型的所有请求，或者可能利用 MVC 路由/控制器组合来提供正确的文件(我还没有看到这样做，但我相信这是可行的).

Microsoft developers can use a HTTP module which intercepts all requests for a given file type(s), or possibly leverage an MVC route/controller combo to serve up the correct file (I haven't seen this done, but I believe it is feasible).

当然，最简单(不一定是最快或最好)的方法是在每个版本中重命名有问题的文件，并在 link 标签中引用更新的路径.

Of course, the simplest (not necessarily the quickest or the best) method is to just rename the files in question with each release and reference the updated paths in the link tags.

• 更改文件名或查询字符串
• 使用每个版本仅发生一次的更改
• 文件重命名优于查询字符串更改
• 始终设置 HTTP 标头以最大限度地发挥缓存的优势

这篇关于强制刷新缓存的 CSS 数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！