为什么获取请求必须在Service Worker中克隆？

Question

在Google的一个服务工作者示例中，缓存和返回请求

js prettyprint-override">self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request)
      .then(function(response) {
        // Cache hit - return response
        if (response) {
          return response;
        }

        // IMPORTANT: Clone the request. A request is a stream and
        // can only be consumed once. Since we are consuming this
        // once by cache and once by the browser for fetch, we need
        // to clone the response.
        var fetchRequest = event.request.clone();

        return fetch(fetchRequest).then(
          function(response) {
            // Check if we received a valid response
            if(!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // IMPORTANT: Clone the response. A response is a stream
            // and because we want the browser to consume the response
            // as well as the cache consuming the response, we need
            // to clone it so we have two streams.
            var responseToCache = response.clone();

            caches.open(CACHE_NAME)
              .then(function(cache) {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
    );
});

另一方面，MDN提供的使用服务工作者的示例并没有克隆请求。

this.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request).then(function(resp) {
      return resp || fetch(event.request).then(function(response) {
        caches.open('v1').then(function(cache) {
          cache.put(event.request, response.clone());
        });
        return response;
      });
    }).catch(function() {
      return caches.match('/sw-test/gallery/myLittleVader.jpg');
    })
  );
});

因此，在谷歌示例中的缓存未命中的情况下：

我理解为什么我们必须克隆响应：因为它被缓存消耗。放置，我们仍然希望将响应返回到请求它的网页。

但是为什么要克隆请求呢？在评论中，它说它被缓存和浏览器用于获取。这到底是什么意思？

• 请求流在缓存中的何处被使用<代码>缓存。放置？如果是这样，为什么不缓存。匹配是否使用请求

Answer 1

fetch请求不会被缓存，因此caches基本上不会使用请求

因此，没有必要克隆。-杰克在他之前的文章中问道。

响应然而，是把或添加到缓存和 /or，可以向下传递然后链作为JSON /text/其他东西-意思是，它们是/可以被消耗的。

我的猜测是，如果你使用或变异了某样东西，那么，你需要克隆它。

读取可能在缓存中两者都不起作用。匹配

我还假设，可能的另一个原因是，请求本身的读取不是通过管道向下传输的，并且缓存只读取一次。匹配如中所示，只读只发生一次，但响应流可能通过管道传输到其他变异/转换/写入管道

只是从溪流规范中抓取。。还没来得及破译所有的东西是怎么加起来的。。也许我会把这个留给专家们

所以，如果我要解释我的理解，直到现在，克隆什么是理想的消费，不麻烦其他。在这种情况下，读取本身不会改变请求/将其写入其他位置，因此无需克隆

Answer 2

在我看来，这条评论相当清楚地说明了为什么该代码的作者认为克隆是必要的：

请求是一个流，只能使用一次。由于缓存和浏览器分别使用了一次和一次，因此我们需要克隆响应。

请记住，请求的主体可以是ReadableStream。如果cache.match必须读取流（或部分读取流）才能知道缓存项是否匹配，则读取的后续读取将继续读取，丢失任何<-plhd--1/>读取。

如果它只在有限的情况下起作用（除非Google示例中的代码完全错误并且没有必要），我不会感到惊讶，因此在许多测试用例中（例如，主体为null或字符串，而不是流）失败可能会起作用。请记住，MDN非常好，但它是由社区编辑的，错误和糟糕的示例确实会定期出现。（这些年来，我不得不修复其中几个明显的错误。）通常社区会发现并修复它们。