Service Worker响应缓存头部

Question

我正在尝试弄清楚服务工作线程在响应的缓存标头方面是如何工作的。我现在已经实施了几个服务工作线程，但从来没有担心过缓存标头，应该将项目缓存多长时间等问题。现在我正在一个企业生产网站上实施它，这些东西实际上真的很重要。

基本上，在使用服务工作线程时，HTTP缓存是否完全被绕过？

那么，我是否需要构建一个框架来处理资源到期/失效，就像HTTP缓存曾经为我们所做的那样？还是我在胡说八道？

如果有人能够提供一些澄清这个问题的帮助，那将非常有帮助。在我看来，有三种可能的情况：

A). 网络请求 => 服务工作线程获取 => （浏览器缓存？）<=> 服务器

B). 网络请求 <=> （浏览器缓存？）<=> 服务工作线程获取 <=> 服务器

C). 网络请求 => 服务工作线程获取 <=> 服务器

我在本地进行了测试，似乎C)是正确的实现方式，即我们开发者为了控制而牺牲了缓存标头/持续时间抽象。

我对此没问题，只是希望在跑去构建一个框架来阅读和遵守服务工作线程中的缓存标头之前，先澄清一下这个问题。

- DanTheNorthernCodeMonkey

Answer 1

A) 是正确的模型。如果一个服务工作者控制着一个页面，所有的网络请求将在查询浏览器缓存或网络之前触发服务工作者的fetch事件处理程序。

反过来，每当服务工作者进行网络请求时，无论是通过显式的fetch()还是隐式地通过cache.add()/cache.addAll()，浏览器的“传统”缓存首先会被查询响应。只有在浏览器缓存中没有有效响应时，才会向服务器发出网络请求。

这有时对你有利，但有时也会暴露你到微妙的错误，如果你不期望这种行为的话。

在https://jakearchibald.com/2016/caching-best-practices/上有一个非常详细的解释，具体涵盖需要避免的事情和利用这种行为的方法。

- Jeff Posnick

---

谢谢，我在推特上@了Jake Archibald，他也说了同样的话。很高兴知道cache.add() / cache.addAll()的相关信息。实际上，在禁用开发工具中的缓存时，我确实发现了许多错误。再次感谢。 - DanTheNorthernCodeMonkey

Answer 2

这取决于您如何配置请求。使用Fetch API，您可以控制请求与浏览器HTTP缓存的交互方式。

例如，您可以将请求的缓存模式设置为no-store，以便绕过HTTP缓存。或者您可以将请求的缓存模式设置为force-cache，这样即使响应已过期，浏览器也会返回缓存的响应：

fetch("some.json", {cache: "force-cache"})
  .then(function(response) { /* consume the response */ });

默认情况下，请求的缓存模式是 default。在这种情况下，请求将像往常一样工作。显然，这仅适用于服务工作者实际执行请求而不是返回某些硬编码响应的情况。

有关更多信息，请查看 Fetch Standard、Request.cache MSN page 和 Using Service Workers MDN page。

- Leonid Vasilev

---

值得注意的是，目前Chrome浏览器不支持cache选项: https://bugs.chromium.org/p/chromium/issues/detail?id=453190 - Jeff Posnick

没错。在Request.cache MDN页面上有一个兼容性表可用。 - Leonid Vasilev