我可以使用 Chrome declarativeNetRequest 完全替代 Chrome webRequest 吗？

Question

我发现 chrome.declarativeNetRequest 仅支持静态规则，我想要的是在重定向/请求等操作之前调用一些自定义方法。到目前为止我还没有找到解决方案。我不确定在 Manifest V3 下是否还能做到这一点。

我的扩展有两个用例。

1. 在重定向之前，我需要执行自定义方法。

    chrome.webRequest.onBeforeRequest.addListener(
        function(requestDetails) {
            //
            // I can get id from requestDetails.url,
            // then do some custom business logic.
            //
            custom_function(requestDetails.url);
            return {redirectUrl:"javascript:"};
        },
        {urls: [ "url_pattern?id=*" ]},
        ["blocking"]
    );

2. 在某些请求之前，我想根据用户的浏览器添加/修改 requestHeaders 。

chrome.webRequest.onBeforeSendHeaders.addListener(
    function (details) {
        details.requestHeaders.push({
            "name": "User-Agent",
            "value": navigator.userAgent + "version_1.0.0"
        });
        return {requestHeaders: details.requestHeaders};
    },
    {
        urls: ["*://url_pattern"],
        types: ["xmlhttprequest"]
    },
    ["blocking", "requestHeaders"]
);

---

@wOxxOm 非常感谢您的耐心解答！
我更喜欢 spinner.html。但我还有另一个问题。

我无法将 regexSubstitution 设置为扩展地址，
我可以使用扩展路径，但相应的捕获组在这里不起作用。

"regexFilter": "google.com*"

以下都是不正确的：

无法使用相应的捕获组。
"extensionPath": "/spinner.html?url=\\0"

无法使用分机地址。
"regexSubstitution": "spinner.html?url=\\0"

我的配置不正确吗？

Answer 1

• 添加/删除标头只能接受静态值，如官方示例所示。

• 在https://crbug.com/1141166中跟踪基于响应标头有条件地添加/删除/修改标头。

• 超出文档中列出的操作功能的重要转换自然无法重新实现。

• 当https://crbug.com/1262147修复后，我们将能够定义一个 declarativeNetRequest 规则，通过regexSubstitution或重定向到扩展程序内的页面extensionPath，并附加原始 URL 作为参数。此页面将充当插页式广告，它将显示某种 UI 或简单的进度微调器，处理 URL 参数，并将当前选项卡重定向到另一个 URL。

  在许多情况下，这种方法会在插页式广告短暂显示时引入闪烁和不必要的视觉干扰，从而使用户感到沮丧，他们可能会完全放弃使用此类扩展。从事扩展工作的 Chromium 团队成员似乎认为这种肮脏的解决方法是可以接受的，因此他们很可能会接受它，另请参阅https://crbug.com/1013582。

• 使用观察性 webRequest（不带'blocking'参数）和 chrome.tabs.update 重定向选项卡。缺点是原始请求将被发送到远程服务器。这种方法显然不适用于 iframe，要重定向这些内容，您必须注入/声明一个内容脚本，您的 webRequest 侦听器将向该脚本发送带有frameId参数的消息。

• 在您的扩展程序中保留一个带有 html 页面的可见选项卡，并在其脚本中使用阻塞 chrome.webRequest。当然，这是一个糟糕的用户体验，尽管得到了 Chromium 扩展团队的认可，但由于许多扩展都使用这种组合，用户的浏览器将不得不保持大量此类选项卡打开。

PS 阻止 webRequest 仍可用于通过策略强制安装的扩展，但这不是大多数用户愿意使用的东西。