坦白：我维护的网站对缓存控制有不同的规则，主要是基于服务器的默认配置，随后是Page Speed＆Y-Slow Firefox插件的建议以及Google Speed Tracer中的Network Resources视图。Cache-Control设置为私有/公共，具体取决于它们说的是什么，仅当Y-Slow提示有问题并且在为Amazon手动gzip文件压缩时似乎需要Vary-Accept-Encoding时，才会修补ETag的/最后修改的标头CloudFront。
当通读有关不同选项及其所做内容的材料时，似乎存在相互矛盾的信息，有关代理损坏的规则和货物偏爱的配置。上面提到的分析工具提供的任何官方信息都很难访问，因为它单独处理每个主题而不是作为一个统一的策略来处理（因此，没有技术的交叉引用）。
例如，如果速度分析工具旨在帮助缓存，那么将速度分析工具对具有ETag的网站和没有ETag的网站的评级相同就没有意义。
平台不可知的高速缓存控制策略有哪些硬性规则和快速规则？
编辑：
一个链接通过杰夫·阿特伍德的文章中精湛的深入解释缓存。
为了记录在案，这是硬性规定和快速规定：
如果使用GZIP等压缩文件 -使用“ cache-control：private”作为代理可能会将压缩版本返回给不支持该压缩版本的客户端（尽管浏览器缓存将保存以此方式标记的文件）。还请记住包括一个“ Vary：Accept-Encoding”，以表示它是可压缩的。
将Last-Modified与ETag结合使用 -皮带和花括号的用法可同时提供两个验证器，而ETag基于文件内容，而不是仅基于修改时间，同时使用了所有基础。注意： 由于某种原因，AOL的PageTest对ETag采取了彻底解决方案。如果您在多台服务器上使用Apache来承载相同的内容，那么除非您确实使用相同的实时文件系统，否则从FileETag指令（即“ FileETag MTime Size”）中排除隐式声明的inode即可将其从ETag中移除。
尽可能使用“缓存控制：公共” -这意味着即使页面的其余部分需要HTTP身份验证，代理服务器（和浏览器缓存）也将返回您的内容。