在“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,它还会创建不透明的响应。不透明响应有一定的限制,包括:
因此,仅在特定情况下才应考虑使用“no-cors”,例如在某些 HTML 元素中缓存和嵌入资源。
结论
以“no-cors”模式禁用 CORS 并不是跨域资源访问的解决方案。相反,使用 CORS 代理是首选方法。通过弥合前端和目标服务器之间的差距,代理添加了必要的标头,使您的代码能够跨源无缝工作。
以上是为什么使用 Fetch 的'no-cors”模式不是处理跨源请求的解决方案?的详细内容。更多信息请关注PHP中文网其他相关文章!