html - 浏览器如何处理多次引用的不可缓存资源？

Question

ThisYahoo Developer Network文章说，浏览器以不同的方式处理在单个HTML中被多次引用的不可缓存资源。我在HTTP/1.1 cache RFC中找不到任何关于这个的规则。
我在chrome上做了一些实验，但我不知道具体的规则。它只加载了一次重复的不可缓存脚本标记。然后我在3个iframe中引用了相同的脚本。第一个触发了一个网络请求，但其他请求是从缓存中提供的。我试图引用与图像src相同的url，这再次触发了网络请求。
有关于这种行为的文档吗？浏览器之间有什么不同？

Answer 1

当客户机决定检索资源时，由RFC2616决定是否可以从缓存返回该资源，或者是否需要从源服务器重新验证/加载该资源（主要是section 14.9但您确实需要阅读整个内容）。
但是，当您在同一页面上拥有同一资源的多个副本时，在按照rfc2616的规则检索第一个副本之后，关于是否检索其他副本的决定现在被html5规范所涵盖（主要在processing model for fetching resources中指定）。
特别是，注意步骤10：
如果资源[…]已经因为其他原因而被下载（例如，该算法的另一调用），并且该请求将与前一个相同（例如相同的接受和源标头），并且用户代理被配置为使得从现有下载中重用数据而不是启动新的数据，然后使用现有下载的结果而不是开始一个新的下载。
这清楚地描述了在决定资源是否可以重用时可能起作用的许多因素。一些要点：
相同的accept和origin头：虽然大多数浏览器在任何地方都使用相同的Accept头，但在internet explorer中，图像与脚本与html的头是不同的。当涉及到帧时，每个浏览器都会发送不同的Referer，虽然Referer没有直接提到，但Accept和Origin只是作为例子。
已经被下载：请注意，这与已经下载的完全不同。因此，如果资源在页面上多次出现，但第一次出现在遇到第二次出现之前已完成下载，则重用选项可能不适用。
用户代理被配置为重用数据：这意味着对我来说，重用或重新检索数据的决定在某种程度上取决于用户代理，或者至少取决于用户选项。
最终的结果是，每个浏览器处理缓存的方式略有不同。即使在特定的浏览器中，结果也可能因时间的不同而不同。
我创建了一个包含三个嵌套框架（即一个包含iframe的页面，它本身包含iframe）和同一脚本的6个副本的测试用例，每个页面上有2个（使用Cache-Control:no-cache使它们不可缓存，但也使用其他变体进行测试，包括max-age=0）。
chrome只加载了一个副本。
internet explorer倾向于变化，可能是基于负载的，但在1到3之间。
Safari加载了3个副本，每个帧一个（即具有不同的Referer头）。
Opera和Firefox加载了所有6个副本。
当我在两个图像（一个在根页面，一个在第一个iframe）和其他一些图像中重用相同的资源作为参考时，行为发生了变化。
chrome现在加载了5个副本，每个页面上每种类型都有一个。虽然chrome中的Accept头对于图像和脚本是相同的，但是头的顺序是不同的，这表明它们可能被不同的处理，并且可能被不同的缓存。
Internet Explorer加载了两个副本，每种类型各一个。不过，考虑到他们只是脚本时的行为，这可能会有所不同。
Safari仍然只有3份，每帧一份。
莫名其妙的是歌剧仍然是6。不知道其中哪部分是脚本，哪部分是图像。但这也可能是根据负载或时间而变化的。
Firefox加载了8个副本，这是他们所期望的。6个脚本，加上2个新图像。
现在，这就是正常查看页面时发生的情况—即，只需在地址栏中输入页面URL。使用f5强制重新加载（或者在safari上使用任何类似的方法）产生了一组完全不同的结果。一般来说，整个重新加载的概念，f5与ctrl-f5，客户机发送的标题等等，在不同浏览器之间也有很大的不同。但那是另一天的话题。
归根结底，从一个浏览器到下一个浏览器的缓存是非常不可预测的，而规范在某种程度上让实现者决定什么对他们最有效。
我希望这已经回答了你的问题。
附加说明：我应该提到，我并没有特意测试每个浏览器的最新版本（特别是safari是一个古老的v4，internet explorer是v9，但其他版本可能都是最新的）。不过，我怀疑这会有多大的不同。在这方面，所有浏览器突然聚合为一致行为的可能性非常小。