“需要 Service Worker Fallback”消息是一个内部错误消息,应该已经随 Chrome 46 消失了。编辑:看起来它可能没有得到修复,但这可能会导致所描述的问题。我们正在跟进该错误。
一个更普遍的回应是,当您处理对经过身份验证的请求的响应时,您需要非常小心处理服务工作者缓存的方式。下面的通用示例代码可能会反过来咬你,我建议你在继续之前回答以下问题:
- 您确定要缓存来自经过身份验证的请求的响应吗?
- 如果是这样,您想对所有经过身份验证的请求/响应使用相同的缓存方法,还是只对特定 API 端点使用其中的一些?请记住,可能存在仅对“新鲜”响应数据有意义的 API 调用。
- 一旦当前用户注销/切换到不同的登录帐户,您有什么机制来处理过期的缓存响应?(如果您继续使用以前缓存的响应进行响应,用户可能会觉得他们仍然作为第一个帐户登录。)
如果您对一种方法感兴趣,您可以阅读与 Google I/O 2015 网络应用程序相关的案例研究的相关部分,该方法采用了一种对我们处理的数据类型有意义的方法。还有一些使用(以前称为)的附加代码也是相关的。但是所有这些问题的答案取决于您的具体用例,所以请在实施任何事情之前考虑清楚。sw-toolbox
shed
编辑:根据对此答案的评论,目的是完全避免服务工作者与经过身份验证的请求进行交互。如果是这种情况(这肯定会简化其他问题的答案),那么您应该能够做一些简单的事情,例如:
self.addEventListener('fetch', event => {
// Only call event.respondWith() if the request doesn't include an
// Authorization header. You can swap in your own header name.
if (!event.request.headers.has('Authorization')) {
event.respondWith(
// Your standard fetch(), caches.match(), etc. logic goes here.
);
}
});
这种方法利用了这样一个事实,即如果服务工作者的fetch
事件处理程序不调用event.respondWith()
,网络请求将最终继续进行,就好像根本没有任何服务工作者参与一样。