如何确保``self.skipwaiting（）`在允许在服务工作者中允许发布请求的过程中有效

发布于 2025-01-27 10:51:02 字数 1105 浏览 1 评论 0原文

我注意到，我的服务工作者在仍有任务时不会响应self.skipwaiting（）。

在我的服务工作者的提取事件中，我看到了使用HTTP POST请求的各种firebase民意调查。

如果我像这样在服务工作者中处理这些请求：

self.addEventListener("fetch", (event) => {
  if (event.request.method === "POST") {
    return event.respondWith(new Response(null, {status: 444}))
  }

  ...
})

然后self.skipwaiting（）始终按预期工作。

但是，如果我执行以下操作：

self.addEventListener("fetch", (event) => {
  if (event.request.method === "POST") {
    return event.respondWith(fetch(event.request))
  }

  ...
})

然后self.skipwaiting（）似乎没有效果。在Chrome的DevTools中，新的服务工作者仍然没有活跃（并且单击蓝色skipwaiting链接也没有效果）。

因此，我似乎必须在确保self.skipwaiting（）有效，并允许Firebase的轮询请求，但不是两者。有没有办法获得self.skipwaiting（）可以在仍允许Firebase的轮询请求的同时工作？

原文

I've noticed that my service worker doesn't respond to self.skipWaiting() when there are still tasks to be run.

In my service worker's fetch event, I see various Firebase polls that use HTTP POST requests.

If I handle these requests in the service worker like so:

self.addEventListener("fetch", (event) => {
  if (event.request.method === "POST") {
    return event.respondWith(new Response(null, {status: 444}))
  }

  ...
})

Then self.skipWaiting() always works as expected.

However, if I do the following:

self.addEventListener("fetch", (event) => {
  if (event.request.method === "POST") {
    return event.respondWith(fetch(event.request))
  }

  ...
})

Then self.skipWaiting() seems to have no effect. In Chrome's devtools, the new service worker still isn't active (and also clicking on the blue skipWaiting link also has no effect).

As a result, it seems that I have to choose between ensuring that self.skipWaiting() works, and allowing Firebase's polling requests, but not both. Is there a way get self.skipWaiting() to work while still allowing Firebase's polling requests?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

沦落红尘 2025-02-03 10:51:02

我看不到您的代码您正在调用self.skipwaiting（），但是有关该功能的主要知识是它“翻转”标志并尝试激活等待服务工作者。我不确定该顺序的哪一部分无法正常工作，而且我也不确定您是否还描述仅在Chrome或其他浏览器中发生的事情。如果您仅在Chrome中看到意外的行为，则提交错误可能是您最好的选择。

话虽如此，为了提供解决方法，我想说您不必在全部。如果您的所有fetch处理程序都不呼叫fetchevent.respondwith（），则将使用默认的浏览器网络行为。因此，您可以像以下内容一样重组Fetch处理程序，也许可以解决此问题。

self.addEventListener("fetch", (event) => {
  if (event.request.method === 'POST') {
    return;
  }

  // Your non-POST response logic goes here.
});

I don't see from your code where you're calling self.skipWaiting(), but the main thing to know about that function is that it "flips" a flag and attempts to activate the waiting service worker. I'm not sure which part of that sequence is not working as expected, and I'm also not sure if you're describing something that happens just in Chrome or in other browsers as well. If you're seeing unexpected behavior just in Chrome, filing a bug is probably your best bet.

That being said, in the interest of providing a workaround, I wanted to say that you don't have to call event.respondWith() inside of a fetch event handler at all. If all your fetch handlers complete without any of them calling fetchEvent.respondWith(), then the default browser networking behavior will be used instead. So you could restructure your fetch handler like the following, and perhaps work around the issue.

self.addEventListener("fetch", (event) => {
  if (event.request.method === 'POST') {
    return;
  }

  // Your non-POST response logic goes here.
});

回复收藏 0 原文

~没有更多了~