3

目前，我们正在使用一种类似于 SE 的方式来破坏浏览器缓存资源（如 css 和 js）：https ://meta.stackexchange.com/questions/112182/how-does-se-determine-the-css-和-js-版本-参数

无论如何，在对 HTTP 标头进行了一些测试之后，我想知道这实际上何时是必要的。这只是 90 年代遗留下来的遗物，还是现代浏览器无法读取 Last-Modified 或 ETags HTTP 标头？

4

1 回答 1

4

缓存问题

当您尝试为易变的 JS 或 CSS 提供服务器并且您不想/不能（例如使用 CDN）时，请依靠 HTTP 缓存指令标头来使浏览器请求新文件。一些较旧的浏览器不响应 HTTP 缓存指令；因此，如果您以他们为目标，则选择有限。在旧浏览器中，一些代理服务器会剥离、无效或忽略代理信息，因为它们有缺陷或充当激进的缓存。因此，使用 HTTP 缓存控制标头将不起作用。在这种情况下，您只是确保您的最终用户在按下 F5 之前不会获得奇怪的功能。

可变 JS/CSS 资源可以来自可通过管理/配置面板编辑的文件/资源​​。造成这种情况的一些原因是主题化、布局编辑或国际化的语言定义文件。

HTTP 1.0

有一些遗留系统使用它。考虑到 Oracle 在其 RDBMS 解决方案中的内置 HTTP 服务器（EGP 网关）仍在使用它。一些代理将 1.1 请求转换为 1.0。古老的浏览器仍然只支持 1.0，但现在这应该是一个相对没有问题的问题。

无论如何，与 HTTP 1.1 的产品相比，HTTP 1.0 使用了一组不同的“原始”控制机制。它们包括了许多 RFC 中未指定的启发式测试，以使缓存工作得相当好。在这两种情况下，缓存通常会导致奇怪的行为，因为交付的内容过时或相同的内容是没有更改的请求。

关于 pragma:no-cache 的说明

仅适用于请求而不是响应；人们不知道的常见事情。它旨在防止中间系统缓存敏感信息。它在 HTTP 1.1 中仍然具有向后支持，但不应使用，因为它已被弃用。

...除非微软说 IE 不这样做：http: //support.microsoft.com/kb/234067

生成内容的输入

另一个原因是基于输入参数生成的 JS 或 CSS。仅仅因为 URL 包含somefile.js并不意味着它必须是文件系统上的真实文件。它可能只是从进程输出的 JS。如果该过程需要根据参数输出不同的内容，GET 参数是实现这一目标的好方法。

考虑页面版本控制。在可能为历史或业务需求保留页面的大型应用程序中，它允许存在相同的命名资源，但如果需要特定版本，则可以根据需要提供服务。您可以将每个版本保存在不同的文件中，或者您可以创建一个流程来输出具有正确版本更改的正确内容。

旧浏览器问题

在 IE6 中，AJAX 请求会受到浏览器缓存的影响。如果您使用未更改的 URL 请求您无法控制的服务，则向 URL 添加一个简单的随机字符串可以规避该问题。

浏览器缓存选项

如果我们考虑有关用户代理缓存设置的 HTTP 1.1 上的 RFC，我们还会看到：

许多用户代理使用户可以覆盖基本的缓存机制。例如，用户代理可能允许用户指定从不验证缓存的实体（甚至是显式陈旧的实体）。或者用户代理可能习惯性地在每个请求中添加“Cache-Control: max-stale=3600”。用户代理不应默认为非透明行为或导致异常无效缓存的行为，但可以通过用户的显式操作显式配置为这样做。

更改用于资源版本控制的 URL 可被视为此类问题的对策。您是否认为值得我将留给读者。

结论

There are reasons to add GET parameters to a file request, but realistically the only reason to do that now (writing as of 2012) is to supply input parameters for dynamically generated scripts and overcoming issues where you can't control the cache headers.

Personally I only use for providing input parameters to scripts that dynamically output initialization scripts, but like everything in development there is always some edge case that adds reason.

于 2012-12-07T18:49:15.493 回答