问题标签 [service-worker]

我在我的页面上注册了一个 ServiceWorker，并希望将一些数据传递给它，以便它可以存储在 IndexedDB 中并稍后用于网络请求（它是一个访问令牌）。

仅使用网络请求并使用 fetch 在 SW 端捕获它们是正确的，还是有更聪明的方法？

给想知道与我类似的事情的未来读者注意：

在 SW 注册对象上设置属性，例如将 self.registration.foo 设置为 service worker 中的函数并在页面中执行以下操作：

结果在TypeError: reg.foo is not a function. 我认为这与 ServiceWorker 的生命周期有关，这意味着您无法修改它并期望将来可以访问这些修改，因此任何带有 SW 的接口都可能必须是 postMessage 样式，所以也许只使用 fetch 是最好的方式去......？

Service Worker本质上充当位于 Web 应用程序之间的代理服务器。

我的担心：ServiceWorker是否也支持离线表单？- 如果是这样，那么我的其他担忧清单是：

1. 它在客户端（存储、会话、本地、数据库）存储不完整的 HTML 表单数据的位置？
2. 它以哪种形式存储用户填写的数据（加密等）
3. 如何解决数据安全/隐私问题？返回用户是同一个用户？- 如果一个用户在公共场所填写了表格并且失去了互联网连接并留下了不完整的表格并继续前进，现在下一个直接用户可以看到最后一个用户离开表格的不完整的表格数据。

我正在使用 Service Worker 编写我的第一个应用程序，并尝试获取注册以便与 pushManager 进行交互。

我可以使用以下任何一种方法来做到这一点：

或者

我应该使用哪个，有什么区别？

Service Worker 和 Shared Worker 有什么区别？

我什么时候应该使用 Service Worker 而不是 Shared Worker，反之亦然？

我的 Service Worker 项目一切正常，但突然我看到以下错误：

尽管我在名为 sw.js 的文件中注册了 SW，但在 index.html:1 上报告了这一点。

我在 Google 上找不到任何东西 - 关于导致此错误发生的原因的任何指导？

在 ServiceWorker 中展示 indexedDB 的例子还不是很多，但我看到的都是这样的结构：

当 ServiceWorker 启动时，这是否可能会失败，如果是，那么在 ServiceWorker 中访问 indexedDB 的可靠方法是什么？

SharedWorker使用消息端口与 交换消息ParentWorker。

家长工人

SharedWorker (worker.js)

Service Worker 呢？有没有类似SharedWorker端口的东西？

我正在根据这篇文章试验 HTML5 ServiceWorker API 。文章中提到

当用户导航到您的站点时，浏览器会尝试重新下载在后台定义服务工作者的脚本文件。如果 service worker 文件与它当前拥有的文件相比甚至有一个字节的差异，它就会认为它是“新的”。

从中我得出的结论是，如果我要更改工作者脚本文件中的任何内容，它将提示浏览器定义一个新版本，当引用旧版本工作者的所有页面都终止时，该版本将启动。

---

编辑：显然浏览器正在缓存serviceworker.js文件本身，这就是为什么没有选择新版本的原因。谁能告诉我如何避免缓存工作文件？我浏览了可用的在线演示（包括MDN和W3C Webmob 的 GitHub 上的演示）

这是我的文件结构：

我将缓存配置为包含以下 URL：

• “/style.css”

oninstall和onactivate事件有什么区别？他们什么时候被解雇？我应该使用哪个事件来初始化诸如 IndexedDB 和 WebSocket之类的千载难逢的操作？

我有一个服务工作者可以捕获我的页面请求（fetch事件），当 URL 与某个模式匹配时，它会获取另一个 URL 并用该新内容替换响应。它非常适用于文本数据（JS、XML...）或二进制数据（例如图像），但是当涉及到视频时，就会出现故障。

我在 OSX 上使用 Chrome 41。

这是我的工人的简化代码：

这是我的 HTML 页面中的简化代码：

第一次加载页面时，worker 安装，所以视频请求没有被捕获，因此失败。但是当您重新加载页面时（不清理缓存），它被成功捕获，并且工作人员成功加载了视频（其检查器中的 HTTP 200），但由于某种原因，主页抛出net::ERR_FAILED.

而且我无法手动读取/流式传输它，因为它来自不同的来源，导致“不透明”响应类型：http ://www.w3.org/TR/service-workers/#cross-origin-resources

更新：更新到 Chrome 42，现在的错误是HTTP 400 Service Worker Fallback Required (from ServiceWorker). 奇怪的是，源代码（第 510 行）表明它只应在缺少 CORS 标头时引发，但这里的模式是no-cors.