当前由Service Worker'fetch'事件提供服务的页面的URL [英] URL of page currently being served by Service Worker 'fetch' event

问题描述

如何获取由服务工作者的获取"事件提供服务的页面的完整URL?

How can I get the full URL of the page which is being serviced by a service worker's 'fetch' event?

"self.location"属性似乎仅引用站点的根URL.例如，如果页面 https://example.com/folder/pagename.html 执行中服务工作者正在拦截的提取操作中，服务工作者的'self.location'属性将返回" https://example.com ".

The "self.location" property seems to only refer to the root URL of the site. For example, if page https://example.com/folder/pagename.html is performing a fetch which the service worker is intercepting, the service worker's 'self.location' property returns "https://example.com".

event.currentTarget.location和event.explicitOriginalTarget.location，event.originalTarget和event.target都返回服务工作者.js文件的URL.

event.currentTarget.location and event.explicitOriginalTarget.location, event.originalTarget, and event.target all return the URL of the service worker .js file.

如何获取触发提取事件的页面的完整URL?

How can I get the full URL of the page that triggered the fetch event?

推荐答案

您有两种通用方法，具体取决于您希望获得的参与程度:

You've got two general approaches, depending on how involved you want to get:

如果请求是针对子资源的，并且包含Referer标头，则该标头的值很可能是发出请求的页面的URL. (有一些注意事项；请阅读此背景信息进行深入研究.)

If the request is for a subresource and includes a Referer header, then there's a decent chance that the value of that header is the URL of the page that made the request. (There are some caveats; read this background info to delve into that.)

在fetch处理程序中，您可以使用以下命令读取该标头的值:

From within a fetch handler, you can read the value of that header with the following:

self.addEventListener('fetch', event => {
  const clientUrl = event.request.referrer;
  if (clientUrl) {
    // Do something...
  } 
});

使用clientId值

另一种方法是使用(可能)在FetchEvent上公开的clientId值，然后使用clients.get(id)或循环浏览clients.matchAll()的输出以找到匹配的WindowClient.然后，您可以读取该WindowClient的url属性.

Use the clientId value

Another approach is to use the clientId value that (might) be exposed on the FetchEvent, and then use clients.get(id) or loop through the output of clients.matchAll() to find the matching WindowClient. You could then read the url property of that WindowClient.

这种方法的一个警告是，查找WindowClient的方法都是异步的，并返回诺言，因此，如果您以某种方式使用客户端窗口的URL来确定是否要调用event.respondWith()，您很不走运(当第一次调用FetchEvent处理程序时，该决定需要同步做出).

One caveat with this approach is that the methods which look up the WindowClient are all asynchronous, and return promises, so if you're somehow using the URL of the client window to determine whether or not you want to call event.respondWith(), you're out of luck (that decision needs to be made synchronously, when the FetchEvent handler is first invoked).

要使此方法起作用，需要支持多种不同的组合，而且我不确定当前哪些浏览器支持我提到的所有功能.例如，我知道Chrome 67确实存在(因为我刚刚在那儿对其进行了测试)，但是您应该在其他浏览器中签入此功能是否对您很重要.

There's a combination of different things that need to be supported in order for this approach to work, and I'm not sure which browsers currently support everything I mentioned. I know Chrome 67 does, for instance (because I just tested it there), but you should check in other browsers if this functionality is important to you.

self.addEventListener('fetch', async event => {
  const clientId = event.clientId;
  if (clientId) {
    if ('get' in clients) {
      const client = await clients.get(clientId);
      const clientUrl = client.url;
      // Do something...
    } else {
      const allClients = await clients.matchAll({type: 'window'});
      const filtered = allClients.filter(client => client.id === clientId);
      if (filtered.length > 0) {
        const clientUrl = filtered[0].url;
        // Do something...
      }
    }
  }
});

这篇关于当前由Service Worker'fetch'事件提供服务的页面的URL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！