关于javascript:CROS跨域请求设置偏重前端

跨域申请

两种后果

• 一种 request 会收不到 response，因为 response 被浏览器拦挡了，内容不通知你
• 另一种申请会基本发不进来，因为浏览器不容许收回那样的 request

simple 申请跨域

条件

1. 申请办法是以下 3 种办法

   • HEAD
   • POST
   • GET

2. HTTP 的头信息不超出以下几种字段

   • 只能有浏览器默认增加的 headers，以及一些 CORS 协定中默认的 headers 比方 Accept 等，更多被容许的 headers，能够看这里
   • Accept
   • Accept-Language
   • Content-Language
   • Lase-Event-ID
   • Content-Type: 只限于三个值 application/x-www-form-urlencoded、multipart/form-data、text/plain

   注：
   一旦一个 request 是 simple request，那么，只管这个申请是跨域的，它也会被浏览器间接放行。然而，在 response 返回的时候，浏览器并不会把 response 间接交给你，而是去查看这个 response 的 headers 中有没有 Access-Control-Allow-Origin，以及这个 header 的 value 蕴含 request 收回的地址（也就是“域”）。如果两个条件都满足，response 会被返回给发出请求的程序；如果没有这个 header 或者 value 不对，response 就会被拦挡下来，因为在浏览器看来，这个 response 不属于你（因为服务器没有明确容许你这个“域”来申请它）。如果你应用的是 chrome 浏览器，在 response 被拦挡下来的时候，console 中会显示一个谬误。

preflight 申请跨域

1. 不是 GET，HEAD，POST 申请；比方是 PUT 申请
2. 蕴含一些非 CORS 协定默认的 headers，比方 Authorization，X-Request-With 或者一些自定义的 headers。
3. Content-Type 不是默认的那 3 种
   正文：
4. 浏览器发送 preflight request（那个 OPTIONS 申请[2]）
5. 浏览器收到 preflight response（也就是刚刚那个 request 的返回）
6. 浏览器依据 preflight response 中的 Access-Control-Allow-Origin, Access-Control-Allow-Headers 以及其余 Access-Control-* 类的 headers 中的 value 来判断网页程序真正要收回的 request 是否符合要求

7. 如果这个 request 符合要求，request 被收回，网页程序能够收到失常的 response（如果不出网络通讯上的意外）；如果这个 request 被断定为不符合要求，这个 request 罗唆就不会被收回。
   以上这些步骤都是同步的，preflight request 和 真正的 request 是有先后顺序的

   跨域时带身信息（Access-Control-Allow-Credentials）

   服务器容许客户端表明身份

   1. 将 Access-Control-Allow-Credentials 设置为 true

   三种默认的表明身份的形式是：

   1. Cookie: 在 request 的 header 中 Cookie 这一项
   2. Authorization: 在 request 的 header 中 Authorization 这一项
   3. 应用了 TLS 证书

让客户端浏览器主动带上身份信息

在进行跨域申请时，浏览器默认不会带上 cookie（这个 cookie 是针对指标域的 cookie，而不是原来“域”的 cookie），然而如果在构建 xhr 对象时，把 XMLHttpRequest.withCredentials 这个属性设为 true，浏览器会主动帮你带上指标域的 cookie

参考文档

https://www.jianshu.com/p/d21…
https://developer.mozilla.org…
https://blog.csdn.net/Daijian…