1

有人试过吗？

这是用例。在第一个请求-响应周期中，这会发生：

请求 1：

GET / HTTP/1.1
...

回应 1

HTTP/1.0 200 OK
Etag: version1
Cache-control: max-age=1

... angly html here
....<link href="mycss.css" >
...

要求 2：

GET /mycss.css HTTP/1.1
...

响应 2（可能已推送）：

Etag: version1
Cache-control: max-age=<duration-of-the-universe>

...
... brackety css ...
...

然后，当浏览器第二次进入同一页面时，它当然会再次获取“/”资源，因为 max-age 非常短：

GET / HTTP/1.1
...
If-not-modified: version1

但如果它在缓存中，它不会获取 mycss.css。但是，服务器可以使用“/”请求的“if-not-modified”标头中存在的验证器来了解客户端的缓存年龄，并可能得出浏览器的 mycss.css 版本太旧的结论. 在这种情况下，甚至在响应之前的请求之前，服务器就可以“承诺”一个新版本的 mycss.css/

根据规范，浏览器应该接受并使用它吗？

4

1 回答 1

2

概述：

我仍然不知道从纯理论方面对我的问题的答案是什么，但至少今天在实践中似乎不可能以这种方式进行缓存破坏:-( 既不是谷歌浏览器也不是火狐。两者如果他们认为缓存中的资源是新鲜的，则拒绝或忽略推送的流。

我还从一个喜欢保持匿名的人那里得到了这个：

浏览器通常会将通过推送接收到的资源放在“非军事区”中，并且只有在客户端请求该资源时，它才会被移动到实际缓存中。因此，即使浏览器在推送时接受它们，仅仅推送随机的东西也不会使它们最终出现在浏览器缓存中。

更新

到 2016 年初，这仍然是不可能的，主要是由于对如何处理以及是否应该允许缺乏共识。如本页所示，即使使用 HTTP/2，解决陈旧资产问题的方法是为每个资产版本创建一个唯一的 URL，然后确保用户在重新访问该页面时收到该新 URL。

于 2015-08-21T15:43:24.500 回答