如何删除有缺陷的服务工作者，或实施“kill switch”？ [英] How can I remove a buggy service worker, or implement a "kill switch"?

问题描述

我正在使用计算机中的服务工作者API，因此我可以掌握如何在现实世界的应用程序中从中受益。

I'm playing with the service worker API in my computer so I can grasp how can I benefit from it in my real world apps.

我遇到了一个奇怪的情况，我注册了一个拦截 fetch 事件的服务工作者，这样它就可以在向源发送请求之前检查其缓存中是否有所请求的内容。
问题是这段代码有一个错误导致函数无法发出请求，所以我的页面留空了;什么都没发生。
由于服务工作者已经注册，第二次加载页面时它会拦截第一个请求（加载HTML的请求）。因为我有这个bug，那个fetch事件失败了，它从不会请求HTML，所有我看到它都是空白页。

I came across a weird situation where I registered a service worker which intercepts fetch event so it can check its cache for requested content before sending a request to the origin. The problem is that this code has an error which prevented the function from making the request, so my page is left blank; nothing happens. As the service worker has been registered, the second time I load the page it intercepts the very first request (the one which loads the HTML). Because I have this bug, that fetch event fails, it never requests the HTML and all I see its a blank page.

在这种情况下，我知道的唯一方法删除糟糕的服务工作者脚本是通过 chrome：// serviceworker -internals / 控制台。
如果此错误进入实时网站，这是解决它的最佳方法吗？

In this situation, the only way I know to remove the bad service worker script is through chrome://serviceworker-internals/ console. If this error gets to a live website, which is the best way to solve it?

谢谢！

推荐答案

我想在这里扩展一些其他答案，并从在将服务工作者推广到生产时可以使用哪些策略的角度来解决这个问题。确保我可以进行任何必要的更改？这些更改可能包括修复您在生产中发现的任何小错误，或者它可能（但希望不会）包括因不可克服的错误而中和服务工作者 - 即所谓的终止开关。

I wanted to expand on some of the other answers here, and approach this from the point of view of "what strategies can I use when rolling out a service worker to production to ensure that I can make any needed changes"? Those changes might include fixing any minor bugs that you discover in production, or it might (but hopefully doesn't) include neutralizing the service worker due to an insurmountable bug—a so called "kill switch".

就本回答而言，我们假设您致电

For the purposes of this answer, let's assume you call

navigator.serviceWorker.register('service-worker.js');

，这意味着您的服务工作者JavaScript资源是 service-worker。 js 。

on your pages, meaning your service worker JavaScript resource is service-worker.js.

我的第一条建议是阅读标准HTTP缓存如何影响服务工作者的JavaScript保持最新的方式。关于此，有大量的错误信息，我希望此Stack Overflow应答清除了部分内容，并说明了如何以及何时检查服务工作者的更新。 要总结那些没有点击其他答案的人，在确定是否请求服务工作者JavaScript的新副本或使用时，您的浏览器将遵守HTTP缓存指令，最长可达1天。缓存的副本。因此，如果您希望能够灵活地快速推出新的服务工作者JavaScript来修复错误，请使用HTTP缓存指令提供 service-worker.js 。 更新：截至2018年6月，默认情况下，所有常绿浏览器都会忽略 Cache-Control 标题。

My first piece of advice is to read up on how standard HTTP caching affects the way your service worker's JavaScript is kept up to date. There's a decent amount of misinformation floating around about this, and I hope that this Stack Overflow answer clears some of it up, and explains how and when service workers are checked for updates. To summarize for folks who don't click through to that other answer, your browser will honor HTTP cache directives, up to a maximum age of 1 day, when determining whether to request a fresh copy of your service worker JavaScript or use a cached copy. Consequentially, if you'd like to have the flexibility to quickly roll out new service worker JavaScript to fix a bug, serve service-worker.js with HTTP caching directives giving it a short or 0 maximum age. Update: As of June 2018, all evergreen browsers will, by default, ignore the Cache-Control header when checking for service worker updates.

一旦你的 service-worker.js 提供了适当的HTTP缓存指令，问题归结为你如何解决初始在 service-worker.js 代码中出现问题。如果这是一个小错误修复，那么您显然可以进行更改并将 service-worker.js 重新部署到您的托管环境中。如果没有明显的错误修复，并且您不想让您的用户在花时间制定解决方案时运行错误的服务工作者代码，保持简单， no-op service-worker.js handy ，如下所示：

Once your service-worker.js is served with appropriate HTTP caching directives, the question boils down to how you go about resolving the initial issue in your service-worker.js code. If it's a small bug fix, then you can obviously just make the change and redeploy your service-worker.js to your hosting environment. If there's no obvious bug fix, and you don't want to leave your users running the buggy service worker code while you take the time to work out a solution, it's a good idea to keep a simple, no-op service-worker.js handy, like the following:

// A simple, no-op service worker that takes immediate control.

self.addEventListener('install', () => {
  // Skip over the "waiting" lifecycle state, to ensure that our
  // new service worker is activated immediately, even if there's
  // another tab open controlled by our older service worker code.
  self.skipWaiting();
});

/*
self.addEventListener('activate', () => {
  // Optional: Get a list of all the current open windows/tabs under
  // our service worker's control, and force them to reload.
  // This can "unbreak" any open windows/tabs as soon as the new
  // service worker activates, rather than users having to manually reload.
  self.clients.matchAll({type: 'window'}).then(windowClients => {
    windowClients.forEach(windowClient => {
      windowClient.navigate(windowClient.url);
    });
  });
});
*/

这应该是你所有的无操作服务-worker.js 需要包含。因为没有注册 fetch 处理程序，所以来自受控页面的所有导航和资源请求将最终直接针对网络，有效地为您提供了相同的行为，如果没有根本不是服务工作者。

That should be all your no-op service-worker.js needs to contain. Because there's no fetch handler registered, all navigation and resource requests from controlled pages will end up going directly against the network, effectively giving you the same behavior you'd get without if there were no service worker at all.

可以更进一步，并使用 Cache Storage API ，或完全取消注册服务工作者。对于大多数常见情况，这可能会过度，并且遵循上述建议应足以让您处于当前用户获得预期行为的状态，并且您已准备好在修复错误后重新部署更新。启动即使是无操作的服务工作人员也会有一定程度的开销，因此您可以选择取消注册服务工作者。

It's possible to go further, and forcibly delete everything stored using the Cache Storage API, or to explicitly unregister the service worker entirely. For most common cases, that's probably going to be overkill, and following the above recommendations should be sufficient to get you in a state where your current users get the expected behavior, and you're ready to redeploy updates once you've fixed your bugs. There is some degree of overhead involved with starting up even a no-op service worker, so you can go the route of unregistering the service worker if you have no plans to redeploy meaningful service worker code.

如果您已经处于某种情况其中你使用HTTP缓存指令服务 service-worker.js ，给它的生命周期比你的用户可以等待的时间长，请记住Shift + Reload 将强制页面在服务工作者控制之外重新加载。并非每个用户都知道如何做到这一点，但这在移动设备上是不可能的。因此，不要依赖Shift + Reload作为可行的回滚计划。

If you're already in a situation in which you're serving service-worker.js with HTTP caching directives giving it a lifetime that's longer than your users can wait for, keep in mind that a Shift + Reload on desktop browsers will force the page to reload outside of service worker control. Not every user will know how to do this, and it's not possible on mobile devices, though. So don't rely on Shift + Reload as a viable rollback plan.

这篇关于如何删除有缺陷的服务工作者，或实施“kill switch”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！