何时需要基于文件名的浏览器缓存破坏技术？

Question

何时需要基于文件名的浏览器缓存破坏技术？

3

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

无论如何，在测试HTTP标头后，我想知道这到底是什么时候必要的。这只是90年代留下的遗物，还是有现代浏览器无法读取Last-Modified或ETags HTTP标头？

- Wade Williams

4

当你的数据被推送到CDN时，这会非常有用，因为当数据发生变化时，让一个大型分布式缓存失效是困难的。 - Mike Christensen

1

这是一个比Josh的+1好得多的答案。 - Diodeus - James MacFarlane

1

我发现在处理CloudFlare方面最有用。 - HellaMad

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Andrew Martinez · Accepted Answer

缓存问题

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

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

HTTP 1.0

仍然有遗留系统在使用它。考虑到Oracle内置的HTTP服务器（EGP网关）在其RDBMS解决方案中仍在使用它。一些代理将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，我们还会看到以下内容：

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

更改资源的版本 URL 可以被认为是对此类问题的一种对策。是否认为这值得做就留给读者自己决定了。

结论

有理由在文件请求中添加 GET 参数，但现实情况下（2012 年写作），现在唯一的原因是为了为动态生成的脚本提供输入参数并克服您无法控制缓存标头的问题。

个人只使用它来提供输入参数以供脚本动态输出初始化脚本使用，但像开发中的所有内容一样，总有一些边缘案例会增加合理性。