摘要:服务器确认允许之后,才发起实际的请求。在预检请求的返回中,服务器端也可以通知客户端,是否需要携带身份凭证包括和认证相关数据。提供了一个接口,用于访问和操纵管道的部分,例如请求和响应。专业的说,完成了一次简单请求。
概念
CORS, Cross-origin resource sharing
跨域资源共享标准新增了一组 HTTP 首部字段,允许服务器声明哪些源站有权限访问哪些资源。另外,规范要求,对那些可能对服务器数据产生副作用的 HTTP 请求方法(特别是 GET 以外的 HTTP 请求,或者搭配某些 MIME 类型的 POST 请求),浏览器必须首先使用 OPTIONS 方法发起一个预检请求(preflight request),从而获知服务端是否允许该跨域请求。服务器确认允许之后,才发起实际的 HTTP 请求。在预检请求的返回中,服务器端也可以通知客户端,是否需要携带身份凭证(包括 Cookies 和 HTTP 认证相关数据)。
Fetch
Fetch API 提供了一个 JavaScript 接口,用于访问和操纵 HTTP 管道的部分,例如请求和响应。它还提供了一个全局 fetch() 方法,该方法提供了一种简单,合乎逻辑的方式来跨网络异步获取资源。
均摘自中文MDN
实验 实验环境搭建 服务端在本地搭建一个服务,返回一个 json ,代码如下
const http = require("http") http.createServer((req, res) => { res.writeHead(200, { "Content-Type": "application/json" }) res.end(JSON.stringify({ author: "nbb3210" })) }).listen(3210)
用浏览器打开http://localhost:3210,观察到返回值
然后再随便找一个还是 http 的网站,例如华为
嗯,意料之中的情形。
简单请求(Simple requests)修改服务端代码,添加 Access-Control-Allow-Origin
res.writeHead(200, { "Access-Control-Allow-Origin": "*", "Content-Type": "application/json" })
再此发送请求
嗯,意料之中的情形。这便完成了一次跨域请求。专业的说,完成了一次简单请求。何为简单请求?
使用下列方法之一:
GET
HEAD
POST
不能设置除以下集合之外的首部字段:
Accept
Accept-Language
Content-Language
Content-Type (需要额外的限制)
Content-Type 的值近限与下列三者之一
text/plain
Multipart/form-data
Application/x-www-form-urlencoded
所以如果我使用了其他的方法或添加其他的首部字段又如何?
哈?还挺严格,再来看看Network
怎么无端出来个 OPTIONS 请求?
预检请求(Preflighted requests)非简单请求就是预检请求了,它会首先使用 OPTIONS 方法发起一个预检请求到服务器,以获取服务器是否允许该实际请求。注意了,浏览器自己根据请求是否为简单请求来发送预检请求,不是咱们一般码农自己写的。
所以修改服务端代码,让它允许自定义头部 Access-Control-Allow-Headers, x-test
const http = require("http") http.createServer((req, res) => { if (res.method === "OPTIONS") { res.writeHead(200, { "Access-Control-Allow-Origin": "*", "Access-Control-Allow-Headers": "x-test" }) res.end() } else { res.writeHead(200, { "Access-Control-Allow-Origin": "*", "Content-Type": "application/json" }) res.end(JSON.stringify({ author: "nbb3210" })) } }).listen(3210)
重新发送一次请求
嗯,没毛病
如果是 DELETE 等其它方法,就用 Access-Control-Allow-Methods
而 Access-Control-Max-Age 则指定了预检请求的结果能够被缓存多久
小结Access-Control-Allow-Origin, Access-Control-Expose-Headers, Access-Control-Max-Age, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers 这一系列的相应首部字段规定了哪些源站通过哪些方式有权限访问哪些资源
Origin, Access-Control-Request-Method, Access-Control-Request-Headers 这一系列请求首部字段无须手动设置,发送跨域请求时,已被自动设置好了
参考文档HTTP访问控制(CORS)
使用 Fetch
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/92172.html
摘要:常用跨域方法总结上篇文章介绍了几种常用的跨域方法常用跨域方法总结,本片为上一篇的补充,对比较重要的详细介绍。出于安全原因,从脚本内发起的跨源请求会受到一定限制。当开发者使用对象发起跨域请求时,它们已经被设置就绪。 常用跨域方法总结(2)——CORS 上篇文章介绍了几种常用的跨域方法:常用跨域方法总结,本片为上一篇的补充,对比较重要的Cross Origin Resource Shari...
摘要:常用跨域方法总结上篇文章介绍了几种常用的跨域方法常用跨域方法总结,本片为上一篇的补充,对比较重要的详细介绍。出于安全原因,从脚本内发起的跨源请求会受到一定限制。当开发者使用对象发起跨域请求时,它们已经被设置就绪。 常用跨域方法总结(2)——CORS 上篇文章介绍了几种常用的跨域方法:常用跨域方法总结,本片为上一篇的补充,对比较重要的Cross Origin Resource Shari...
摘要:常用跨域方法总结上篇文章介绍了几种常用的跨域方法常用跨域方法总结,本片为上一篇的补充,对比较重要的详细介绍。出于安全原因,从脚本内发起的跨源请求会受到一定限制。当开发者使用对象发起跨域请求时,它们已经被设置就绪。 常用跨域方法总结(2)——CORS 上篇文章介绍了几种常用的跨域方法:常用跨域方法总结,本片为上一篇的补充,对比较重要的Cross Origin Resource Shari...
摘要:今天这篇文章,我们会介绍几种常见的方法和其中存在的问题,并提出如何基于请求拦截,快速解决跨域和代理问题的方案。因为没有修改该请求,只是延迟发送,这样就保持了原请求与业务服务器之间的所有鉴权等相关信息,由此解决了跨域访问无法携带的问题。 近几年,随着 Web 开发逐渐成熟,前后端分离的架构设计越来越被众多开发者认可,使得前端和后端可以专注各自的职能,降低沟通成本,提高开发效率。 在前后端...
阅读 2786·2021-11-18 10:02
阅读 3639·2021-11-15 17:59
阅读 2279·2021-09-06 15:00
阅读 3324·2019-08-29 16:58
阅读 1036·2019-08-26 10:34
阅读 1563·2019-08-26 10:15
阅读 1268·2019-08-26 10:11
阅读 2669·2019-08-23 18:33