使用 ServiceWorker 缓存 iframe 请求答案

【问题标题】：Cache iframe request with ServiceWorker使用 ServiceWorker 缓存 iframe 请求
【发布时间】：2017-10-11 10:41:10
【问题描述】：

我正在尝试使用我的 ServiceWorker（使用 sw-toolbox.js）缓存 iframe 的请求。

但无论我如何尝试，都不会像 Chrome 网络选项卡告诉我的那样，从 ServiceWorker 提供文件。

这是我的 service-worker.js：

'use strict';
importScripts('./build/sw-toolbox.js');

self.toolbox.options.cache = {
    name: 'ionic-cache'
};

var static_urls = [
    'https://quiqqer.local/test?app=1',
    'https://quiqqer.local/calendar?app=1'
];

self.toolbox.precache(static_urls);

self.toolbox.router.any('/(.*)', self.toolbox.cacheFirst, {origin: 'https://quiqqer.local'});

self.addEventListener('install', function (event)
{
    self.skipWaiting();
});

self.toolbox.router.default = self.toolbox.cacheFirst;

self.toolbox.precache() 函数正确地向我的 static_urls 发出请求，正如我在“网络”选项卡中看到的那样。

但所有来自 iframe 的请求（转到 https://quiqqer.local/）似乎都没有通过 ServiceWorker 路由。

我做错了什么？还是不能缓存 iframe 请求？

使用 Linux 在 Chromium 上运行。

提前致谢

【问题讨论】：

标签： javascript caching iframe service-worker

【解决方案1】：

可能有一个官方的 HTML 规范提供了更规范的答案，但我只是从MDN documentation 中摘录：

HTML 元素代表一个嵌套的浏览上下文，有效地将另一个 HTML 页面嵌入到当前页面中。 ... 每个浏览上下文都有自己的会话历史和活动文档。包含嵌入内容的浏览上下文称为父浏览上下文。

您可以想象<iframe> 中发生的事情，包括加载<iframe> 的src 本身的请求，相当于将<iframe> 加载到单独的选项卡中会发生的情况.除非控制父浏览上下文（即您的顶级页面）的服务工作者也恰好在其范围内包含<iframe> 的src，否则该服务工作者将无法控制最初加载<iframe>或来自<iframe> 的请求。

【讨论】：

如果example.com 的页面创建了<iframe src="https://example.com/1.jpg">，它是否应该有权访问父 SW 中的请求和响应？如果域是https://static1.example.com/1.jpg 之类的子域怎么办？
创建<iframe src="https://example.com/1.jpg"> 将导致fetch 请求的fetch 事件，可供example.com 的SW 拦截。（除了你为什么要用 JPG 作为src 来代替<iframe>？）https://static1.example.com/ 不是这种情况，因为它的来源不同。
jpg 只是为了举例。我的用例是一个遗留应用程序，其中下载实现为<iframe src="...">，源指向外部 URL。通常在子域中，有时在外部 CDN 中。有时响应是错误的。我试图拦截此类下载的状态并在出现错误时采取行动。但是，据我所知，现在是不可能的。