javascript - 什么时候真正需要基于文件名的浏览器缓存清除?

标签 javascript css caching header

目前,我们正在使用一种方法以类似于 SE 的方式破坏浏览器缓存的资源,如 css 和 js:https://meta.stackexchange.com/questions/112182/how-does-se-determine-the-css-and-js-version-parameter

无论如何,在对 HTTP header 进行了一些测试之后,我想知道什么时候才真正需要这样做。这只是 90 年代遗留下来的遗物,还是现代浏览器无法读取 Last-Modified 或 ETags HTTP header ?

最佳答案

缓存问题

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

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

HTTP 1.0

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

无论如何,HTTP 1.0 使用一组不同的控制机制,与 HTTP 1.1 的产品相比,这些机制是“原始的”。它们包括许多未在 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 user agent cache settings我们还看到了这一点:

Many user agents make it possible for users to override the basic caching mechanisms. For example, the user agent might allow the user to specify that cached entities (even explicitly stale ones) are never validated. Or the user agent might habitually add "Cache- Control: max-stale=3600" to every request. The user agent SHOULD NOT default to either non-transparent behavior, or behavior that results in abnormally ineffective caching, but MAY be explicitly configured to do so by an explicit action of the user.

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

结论

将 GET 参数添加到文件请求是有原因的,但实际上现在(截至 2012 年编写)这样做的唯一原因是为动态生成的脚本提供输入参数并克服无法控制缓存的问题标题。

我个人只用于为动态输出初始化脚本的脚本提供输入参数,但就像开发中的所有内容一样,总会有一些边缘情况增加原因。

关于javascript - 什么时候真正需要基于文件名的浏览器缓存清除?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13769088/

相关文章:

php - Magento 缓存两次添加内容

javascript - FullCalendar 多个事件

javascript - 简单 JSON 调用的 console.log() 错误行为

javascript - 如何在Next js上将数据从express服务器发送到客户端?

javascript - d3 嵌套 SVG 在 Firefox 中的绘制方式与在 Chrome 中的绘制方式不同

java - LoadingCache停止自动刷新并仅提供陈旧数据

javascript - 显示 javascript 执行进度

css - Vue.js 转换 - 第一个入口不工作

html - 仅使用 CSS 的元素重新定位(Volusion 详细信息)

apache - 上传的文件在浏览器中不可见,除非我强制不重新加载缓存浏览器