首页 >web前端 >js教程 >为什么使用 Fetch 的'no-cors”模式不是处理跨源请求的解决方案?

为什么使用 Fetch 的'no-cors”模式不是处理跨源请求的解决方案?

Susan Sarandon
Susan Sarandon原创
2024-12-14 09:33:11243浏览

Why is using Fetch's 'no-cors' mode not the solution for handling cross-origin requests?

在“no-cors”模式下使用 Fetch

Fetch API 提供了一种向服务器发出请求的便捷方法。但是,跨域访问资源时,可能会遇到“请求的资源上不存在‘Access-Control-Allow-Origin’标头”的错误。此错误表示同源策略施加的安全限制。

要在 Fetch 中禁用 CORS,很容易使用 { mode: 'no-cors' } 选项。然而,这种方法是不正确且不可取的。

'no-cors'模式:一个失误

'no-cors'模式本质上阻止了浏览器访问响应正文和标题。这意味着您的代码将无法处理或使用获取的数据。重要的是要了解禁用 CORS 不会覆盖同源策略。它只会影响浏览器处理响应的方式。

解决方案:CORS 代理

您应该使用 CORS 代理,而不是禁用 CORS。代理充当前端代码和目标服务器之间的中介。当您通过代理发送请求时,它会将请求转发到服务器,接收响应,并在将其传回代码之前添加必要的 Access-Control-Allow-Origin 标头。这允许您的代码跨源访问响应。

要设置 CORS 代理,您可以使用现有服务或使用 Heroku 等平台部署自己的代理。

了解跨域请求

需要注意的是,即使你可以在Postman中跨域访问资源,浏览器也会强制对 Web 应用程序中运行的前端代码的限制。为了确保跨源资源访问,响应必须包含 Access-Control-Allow-Origin 标头。

不透明响应:警告

虽然 'no-cors'模式禁用 CORS,它还会创建不透明的响应。不透明响应有一定的限制,包括:

  1. 无法读取响应标头或正文内容
  2. 无法在非 HTML 上下文中使用响应(例如 $

因此,仅在特定情况下才应考虑使用“no-cors”,例如在某些 HTML 元素中缓存和嵌入资源。

结论

以“no-cors”模式禁用 CORS 并不是跨域资源访问的解决方案。相反,使用 CORS 代理是首选方法。通过弥合前端和目标服务器之间的差距,代理添加了必要的标头,使您的代码能够跨源无缝工作。

以上是为什么使用 Fetch 的'no-cors”模式不是处理跨源请求的解决方案?的详细内容。更多信息请关注PHP中文网其他相关文章!

声明:
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn