强制刷新缓存的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的网址？

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            |
+---------------------+--------------------+-------------------------+

不过，请记住，浏览器和网络服务器并不总是符合我们的预期。着名示例： 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语法中的示例，但适用于几乎任何服务器处理语言。}

...由于一些应用程序传统上使用GETs和HEADs
查询URL（在rel_path部分中包含？）执行具有显着副作用的
操作，缓存不能将
响应处理为新的URI，除非服务器提供明确的
到期时间。这特别意味着这些URI的HTTP / 1.0
服务器的响应不应该从缓存中获取。

...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.

如果您只维护几个网址，则可以手动修改这些网址，以包含内部版本号或日期：

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时产生新的请求，返回304s。

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).

这个答案显示了一些简单而优雅的选项

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).

当然，最简单的（不一定是最快的最好的）方法是仅仅重命名每个版本的相关文件，并引用链接标签中的更新路径。

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标头以最大化缓存的好处

• Change the file name or query string
• Use a change that only occurs once per release
• File renaming is preferable to a query string change
• Always set HTTP headers to maximize the benefits of caching

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