fetch() 在扩展程序中有效,但在 Chrome 控制台/片段中失败

我的 Chrome 扩展程序执行一个正常工作的获取请求.因为使用代码段进行测试更快,所以我想在 Chrome 控制台或 Chrome 代码段中执行完全相同的操作.最小的例子:

fetch(url, {方法:获取";}).then(response => response.text()).then(html => console.log(html)).catch(错误 => 控制台.log(错误))

不幸的是,我只得到了

TypeError: Failed to fetch 错误和

在 Chrome 的内联错误标记中加载资源失败:net::ERR_FAILED

在我的 Chrome 扩展中,我遇到了一个 CORS 问题,所以我在我的 AWS Lambda 函数中所做的就是将标头设置为

const headers = {'内容类型':'应用程序/json',访问控制允许标头":内容类型",访问控制允许来源":*",访问控制允许凭据": 真的};

所以我假设 CORS 不是这里的问题.但我似乎无法弄清楚在扩展程序中运行请求与在控制台/片段中运行请求会产生什么差异.我会在这里遗漏什么?

我也没有在 AWS CloudWatch 中看到请求,所以我想它甚至不会离开我的机器.我正在对安装了 0 个扩展的 Chrome 用户进行测试,在隐身模式中也会发生同样的情况

为了排除我的服务器的任何问题,我还插入了

链接的解释"给出了

排队:浏览器在以下情况下将请求排队:

  • 有更高优先级的请求.

  • 已经有六个 TCP 连接为此源打开,即极限.仅适用于 HTTP/1.0 和 HTTP/1.1.

  • 浏览器在磁盘缓存中短暂分配空间

停止:请求可能由于排队中所述的任何原因而停止.

更高的优先级似乎很奇怪,6个连接也不是问题,因为我在测试之前重新启动了浏览器,磁盘缓存问题听起来也不是问题.我不是没有防病毒的 macOS

解决方案

我设法找到了问题所在.为了避免通过在我的 AWS 仪表板选项卡中打开 Chrome 开发人员控制台来潜在地授予我的请求特权,我创建了一个新选项卡 (chrome://new-tab-page/) 并在控制台.这返回了所描述的错误.

当我用示例代码更新我的问题后,我想先确认它是否正在运行,然后再要求某人尝试它是否可以在他们的机器上运行.为了快速运行时验证,我在 Stackoverflow 选项卡中打开了控制台,它工作正常.我只想检查代码是否可以解释,但结果实际上返回了结果.这同样适用于我的 AWS 实例,如果我在 https 网站上运行它就可以正常工作.不知道为什么没有记录,而是磁盘缓存".被提及为潜在错误.

tldr 不要在新选项卡中为控制台中的请求打开 Chrome 控制台,请使用任何网站. 这可能与 CORS 标头有关,仅当请求没有空标头时才有效以也许(?)开头

我特别避免使用网站控制台实例进行测试,因为我想防止 AWS 页面上的潜在 cookie 执行其他人无法在他们的计算机上执行的操作.好想坏结果哈哈

非常感谢您提出帮助的意见,非常感谢.

My Chrome Extension performs a get request which works fine. Because testing is faster with snippets, I want to do the exact same thing in the Chrome Console or in the Chrome Snippets. Minimal example:

fetch(url, {
    method: "GET"
}).then(response => response.text())
  .then(html => console.log(html))
  .catch(error => console.log(error))

Unfortunately, there I only get

TypeError: Failed to fetch for the error and

Failed to load resource: net::ERR_FAILED in Chrome's inline error marker

In my Chrome Extension I ran into a CORS issue so what I did in my AWS Lambda function was to set the headers to

const headers = {
    'Content-Type': 'application/json',
    "Access-Control-Allow-Headers" : "Content-Type",
    "Access-Control-Allow-Origin" : "*",
    "Access-Control-Allow-Credentials" : true
};

so I suppose CORS isn't the problem here. But I can't seem to figure out as to what differences it could make to have the requests run in the Extension vs. in the console/snippets. What could I be missing here?

I also do not see the request in AWS CloudWatch so I suppose it doesn't even leave my machine. I am testing on a Chrome User that has 0 extensions installed, same happens in incognito

To circle out any issues with my server I have also inserted the examples from https://lockevn.medium.com/snippet-to-fetch-remote-rest-api-and-display-in-console-of-chrome-devtool-6896a7cd6041

async function testGet() {
    const response = await fetch('https://jsonplaceholder.typicode.com/posts')
    console.log(await response.json())
}

async function testPost() {
    let r = await fetch('https://jsonplaceholder.typicode.com/posts', {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
        },
        body: JSON.stringify({
            lockevn: 1
        }),
    })
    console.log(await r.json())
}


testGet()

testPost()

Chrome's Network tab shows the request as stalled

The linked 'explanation' gives

Queueing: The browser queues requests when:

  • There are higher priority requests.

  • There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.

  • The browser is briefly allocating space in the disk cache

Stalled: The request could be stalled for any of the reasons described in Queueing.

Higher priority seems odd, 6 connections can't be the issue either since I have restarted my browser before testing, and the disk cache issue doesn't sound like the problem either. I'm not macOS with no anti virus

解决方案

I managed to find the issue. In order to avoid potentially privileging my requests by opening the Chrome Developer Console in my AWS dashboard tab, I have created a new tab (chrome://new-tab-page/) and performed the requests in the console. This returned the errors described.

When I have updated my question with the example code I wanted to confirm if it was running before asking someone to try it if it works on their machine. For quick runtime-validation I opened the Console in the Stackoverflow tab and it worked. I only wanted to check if the code can be interpreted but it turned out to actually return a result. The same is valid for my AWS instance, if I run it on a https website it works fine. No idea why this is not documented but "disk cache" is mentioned as a potential error.

tldr don't open Chrome Console in new tab for requests in the console, use any website. This may have to do with CORS headers only working if the request doesn't have empty headers to begin with maybe (?)

I specifically avoided using a website console instance for testing because I wanted to prevent potential cookies on the AWS page from doing something that someone else couldn't do on their machine. Good thinking bad result haha

Thank you so much for your comments suggesting the help, much appreciated.

相关文章