javascript - 网络请求 API : How to get the requestId of a new request?

Question

chrome.webRequest API 具有请求 ID 的概念(来源:Chrome webRequest documention):

Request IDs

Each request is identified by a request ID. This ID is unique within a browser session and the context of an extension. It remains constant during the the life cycle of a request and can be used to match events for the same request. Note that several HTTP requests are mapped to one web request in case of HTTP redirection or HTTP authentication.

您甚至可以使用它来关联请求，甚至跨重定向。但是，当使用 fetch 或 XMLHttpRequest 启动新请求时，如何最初获取 id？

到目前为止，我还没有找到比使用请求的 URL 更好的方法来在新请求和 requestId 之间建立初始链接。但是，如果对同一资源存在重叠请求，则这是不可靠的。

问题:

• 如果您发出新请求(使用 fetch 或 XMLHttpRequest)，如何可靠地访问 requestId？
• fetch API 或 XMLHttpRequest API 是否允许访问 requestId？

我想做的是使用 webRequest API 提供的功能来修改单个请求，但我想确保我不会意外修改其他待处理的请求。

Answer 1

据我所知，fetch 或 XHMLHttpRequest API 没有直接支持。另外，我不知道完全可靠的方法来获取 requestId。

我最终做的是安装 onBeforeRequest监听器，存储requestId，然后立即再次删除监听器。例如，它可能如下所示:

function makeSomeRequest(url) {

  let listener;
  const removeListener = () => {
    if (listener) {
      chrome.webRequest.onBeforeRequest.removeListener(listener);
      listener = null;
    }
  };

  let requestId;
  listener = (details) => {
    if (!requestId && urlMatches(details.url, url)) {
      requestId = details.requestId;
      removeListener();
    }
  };
  chrome.webRequest.onBeforeRequest.addListener(listener, { urls: ['<all_urls>'] });

  // install other listeners, which can then use the stored "requestId"
  // ...

  // finally, start the actual request, for instance
  const promise = fetch(url).then(doSomething);

  // and make sure to always clean up the listener
  promise.then(removeListener, removeLister);
}

它并不完美，匹配 URL 是我 Unresolved 细节。您可以简单地比较 details.url 是否与 url 相同:

function urlMatches(url1, url2) {
  return url1 === url2;
}

请注意，不能保证您看到相同的 URL，例如，如果针对 http://some.domain.test 发出请求，您将看到 http:///some.domain.test/ 在你的监听器中(有关详细信息，请参阅我的 other question)。或者 http:// 可能已替换为 https:// (这里我不确定，但这可能是因为其他扩展名，如 HTTPS Everywhere )。

这就是为什么上面的代码只能被视为这个想法的草图。只要您不向同一 URL 发起多个请求，它在实践中似乎就足够好了。尽管如此，我还是有兴趣了解解决该问题的更好方法。