JavaScript 中的 HTTP 跨域要求

2019年8月31日 187次阅读 来源: serenader

原文宣布于我的博客：https://blog.serenader.me/htt…

自从我打仗前端以来，接办的项目内里很大部份都是前后端星散的，后端只供应接口，前端依据后端接口衬着出现实页面。个人以为这是一个挺好的形式，前后端各自担任各自的模块，分工明白，而且也给前端更大的发挥空间。

与以前套模板的形式差别，前后端星散今后，前端跟后端的沟通绝大部份都是经由历程前端主动向后端提议要求来完成的。而前端的要求又绝大部份是由 Ajax 组成的，Ajax 是一种异常轻易的猎取数据的体式格局。然则，一旦 Ajax 碰上跨域，那末题目就会贫苦许多。这篇文章重要梳理了我在项目开辟内里遇到的一些关于跨域要求的题目，固然也会有一些关于跨域要求的一些背景学问。PS：文末有个小彩蛋哦?

严格来讲，跨域要求并不仅仅只是 Ajax 的跨域要求，而是关于一个页面来讲，只需它要求了其他域名的资本了，那末这个历程就属于跨域要求了。比方，一个带有其他域名的 src 的 <img> 标签，以及页面中引入的其他第三方的 CSS 款式等。

关于 img 以及 CSS 而言，跨域要求本身并没有更多的平安题目，因为这些要求都属于只读要求，并不会对源资本形成副作用。而如果跨域要求是从剧本内里发出去的，因为剧本具有高度灵活性，浏览器出于平安斟酌，会依据同源战略来限定它的功用，使得平常状况下，剧本只能要求同源的资本。如果页面确切须要经由历程剧本要求其他网站的资本，那末就应当在跨域资本共享（CORS）的机制下事情。

等等同砚，什么叫做同源战略？

同源战略（Same-origin policy）

关于两个页面（资本）而言，只需他们满足以下三个前提则称他们相符同源战略：

  1. 协定雷同

  2. 端口雷同

  3. 域名雷同

别的，about:blank 和 javascript: 继承加载这些资本的页面的 origin。data: 的资本差别，本身会具有一个空的平安的上下文。

别的，子域可以经由历程JS 设置 document.domain 来经由历程同源战略。如：

在子域 http://a.example.com/test.html 的页面中，经由历程 JS 设置 document.domain='example.com' ，则当前页面与 http://example.com/page.html 相符同源战略。

简朴的说，关于页面 http://www.example.com/page1.html 来讲，以下页面与它都不相符同源战略，剧本没法直接要求这些资本：

  • https://www.example.com/page1.html : 协定差别

  • http://www.example.com:81/page1.html : 端口差别

  • http://another.example.com/page1.html : 域名差别

那末，什么又是 CORS 呢？

CORS（Cross-Origin Resource Sharing）

CORS 本质上是划定了一系列的 HTTP 头来作为推断剧本是不是可以完成跨域要求。在相识这些要求头之前，先来看看跨域要求有哪些范例。

经由历程剧原本发出要求有两种体式格局，一种是经由历程建立 XMLHttpRequest 的体式格局来发出要求，别的一种是经由历程 fetch API 来完成要求。

平常来讲，跨域要求可以大抵分为两种，个中一种称之为简朴的要求，其相符以下前提：

  • 要求的要领是 GET、 POST、 HEAD 个中之一。

  • 除了浏览器自动带上的要求头（如 Connection User-Agent 等）以外，只许可下面几种要求：头

    • Accept

    • Accept-Language

    • Content-Language

    • Content-Type

  • Content-Type 要求头的值只能是 application/x-www-form-urlencoded、 multipart/form-data、 text/plain 个中之一。

反之，如果有违犯上面三条划定规矩中的恣意一条，那末即不是简朴的跨域要求。非简朴的跨域要求相干于简朴的跨域要求来讲区分在于，要求在发出去之前，浏览器会先发送一个 preflighted 要求，用来向效劳器端确认接下来要举行的要求是不是是被许可的。

Preflight 要求

在现实项目开辟中，在运用 XHR 或许 fetch API 要求接口的时刻许多状况下都邑带上一些分外的特别要求头，或许运用特别的 HTTP 要领，如 PUT、DELETE 等（常见于 Restful 接口）。因为多了分外的要求头或许运用了特别的 HTTP 要领，浏览器就将这些要求视为非简朴的跨域要求，将会在现实要求发出去之前先自动发出一个 preflight 要求，也就是一个 OPTIONS 要求。

OPTIONS 要求会将当前的跨域要求所运用的特别 HTTP 要求头和 HTTP 要求要领发送给效劳器端，如 Access-Control-Request-Method 和 Access-Control-Request-Headers 。效劳器端接收到 OPTIONS 要求后返回相应的相应头。浏览器依据返回的相应头再来推断该跨域要求是不是被许可的。当浏览器剖断 OPTIONS 要求经由历程了，真正的要求才会发出。如以下则是一个带有 OPTIONS 要求以及真正的 GET 要求的相应头和要求头：

OPTIONS /api4 HTTP/1.1
Host: us1.serenader.me:3333
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Access-Control-Request-Method: PUT
Origin: http://us1.serenader.me:3334
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
Accept: */*
Referer: http://us1.serenader.me:3334/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4,fr;q=0.2
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,POST,PUT,DELETE
Content-Type: text/html; charset=utf-8
Content-Length: 2
ETag: W/"2-REvLOj/Pg4kpbElGfyfh1g"
Date: Thu, 19 Jan 2017 15:21:15 GMT
Connection: keep-alive
PUT /api4 HTTP/1.1
Host: us1.serenader.me:3333
Connection: keep-alive
Content-Length: 0
Pragma: no-cache
Cache-Control: no-cache
Origin: http://us1.serenader.me:3334
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
Accept: */*
Referer: http://us1.serenader.me:3334/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4,fr;q=0.2
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: text/html; charset=utf-8
Content-Length: 2
ETag: W/"2-REvLOj/Pg4kpbElGfyfh1g"
Date: Thu, 19 Jan 2017 15:21:15 GMT
Connection: keep-alive

相识了简朴跨域要求以及会发出 preflight 要求的非简朴跨域要求以后，我们再来看看究竟是哪些 HTTP 头在决议这些跨域要求的「宿命」。

为了协助读者更好地明白这些 HTTP 头的作用，我编写了一个简朴的 demo ，开源在了 GitHub 上，感兴趣的可以到 这个链接检察代码，或许接见这个在线 demo 预览效果：http://us1.serenader.me:3334/。记得加载完页面后翻开 Chrome 的控制台来检察细致的要求信息。

Access-Control-Allow-Origin

Access-Control-Allow-Origin 是一个相应头，它指定了当前资本许可被哪些域名的剧本所要求到。

跨域要求（不管简朴要求还黑白简朴要求）在发出时都邑带上 Origin 要求头，用来表明当前发出要求的是哪个域名。此时效劳器端的相应头内里必需包含一个 Access-Control-Allow-Origin 而且该值婚配 Origin 要求头，这时刻该跨域要求才有能够胜利。不然一概失利。

Access-Control-Allow-Origin 是第一道门坎。其值的婚配划定规矩是：

  • 如果其值是通配符 * 的话，则许可一切的域名举行跨域要求

  • 如果其值是指定的某个牢固域名，那末只许可该域名举行跨域要求，其他域名将会失利

  • 如果其值是带有通配符的域名，如 *.example.com ，那末则许可该域名以及该域名的子域名举行跨域。

详细可以寓目 demo，demo-0 展现了当剧本要求没有设置跨域头的接口时，要求被浏览器阻拦了的状况：

《JavaScript 中的 HTTP 跨域要求》

demo-1 则展现了接口有设置 Access-Control-Allow-Origin 相应头，然则并不是剧本要求的域名，此时浏览器会报这类错：

《JavaScript 中的 HTTP 跨域要求》

只要设置了准确的 Access-Control-Allow-Origin 相应头要求才可以平常接收到相应，如demo-2，此时的要求头和相应头为：

GET /api2 HTTP/1.1
Host: us1.serenader.me:3333
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Origin: http://us1.serenader.me:3334
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
Accept: */*
Referer: http://us1.serenader.me:3334/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4,fr;q=0.2
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: text/html; charset=utf-8
Content-Length: 2
ETag: W/"2-REvLOj/Pg4kpbElGfyfh1g"
Date: Thu, 19 Jan 2017 15:03:33 GMT
Connection: keep-alive

关于简朴的跨域要求来讲，平常只须要经由历程 Access-Control-Allow-Origin 这个相应头则可以要求胜利（带 cookie 等状况先不斟酌，会在下面议论）。而当要求不是简朴的跨域要求，状况就比较复杂。

Access-Control-Allow-Headers

Access-Control-Allow-Headers 是用来通知浏览器当前接口所许可带上的特别要求头是哪些。这个 HTTP 头平常会出如今 OPTIONS 要求的相应头中。

当要求设置了一个特别的要求头而且所要求的接口并没有设置 Access-Control-Allow-Headers 相应头时，会报以下毛病，如 demo-3 所示：

《JavaScript 中的 HTTP 跨域要求》

上面的截图展现了要求附带了一个 X-Custom-Header 的要求头，然则要求在 preflight 阶段就失利了，如果要让要求胜利完成的话，则必需在 OPTIONS 要求的相应内里配上 Access-Control-Allow-Headers: X-Custom-Header。

Access-Control-Allow-Methods

与上一个 HTTP 头类似，Access-Control-Allow-Methods 通知浏览器当前接口许可运用哪些 HTTP 要领去要求它。这个 HTTP 头平常也是在 OPTIONS 要求的相应头中才有意义。当没有经由历程这个相应头时，会报如许的毛病：

《JavaScript 中的 HTTP 跨域要求》

一样的，上面的截图在 preflight 阶段就失利了。如果要让要求胜利实行的话，那末须要设置相应头为：Access-Control-Allow-Methods: GET,POST,PUT。

Access-Control-Max-Age

因为 OPTIONS 要求的存在，关于一个非简朴要求来讲，现实发出去的要求会有两个。这多多少少会糟蹋带宽，毕竟这个校验应当只会在第一次发作罢了，一旦经由历程校验，在接下来的一段时候里，再次要求该接口的话，那末现实上 OPTIONS 要求则没有必要再发出。

幸亏，有个叫做 Access-Control-Max-Age 的相应头可以完成如许的功用。这个相应头指定了要求一旦经由历程了 preflight 要求以后，会在多长时候内不必再次触发 preflight 要求。从而到达削减现实要求，削减带宽糟蹋的题目。

Access-Control-Allow-Credentials

默许状况下， 任何跨域要求都不会带上任何身份凭据的，这些身份凭据包含：

  • cookie

  • 与身份认证相干的要求

  • TLS 客户端证书

但是，在大多数状况下，我们须要要求带上 cookie ，那末则须要开启跨域要求的 withCredentials 选项。

想要手动开启传输 cookie 的话，有以下要领；

  • XHR：为 XHR对象设置 xhr.withCredentials = true 。

  • fetch: 传入的参数选项内里开启 credentials fetch(url, { credentials: 'include' })

开启了 withCredentials 以后，要求在发出去的时刻就会默许加上 Cookie。

但是，除了须要在前端中手动开启 withCredentials 以外，效劳器端也须要有相应相应头支撑，要求才会胜利。

Access-Control-Allow-Credentials 这个相应头则是表明了当前要求的资本是不是许可附带身份凭据。当其值为 true 时要求才胜利，不然会失利，失利内容以下：

《JavaScript 中的 HTTP 跨域要求》

可以参考 demo-7寓目要求头以及相应头。

别的，一旦开启了 withCredentials 选项，效劳器端的 Access-Control-Allow-Origin 相应头就不能是通配符，只能是牢固的一个域名，不然会要求失利。详细毛病内容为：

《JavaScript 中的 HTTP 跨域要求》

demo-8 和 demo-9 离别演示了当要求带上 cookie 时，相应头设置为通配符的状况以及相应头有准确设置为详细域名的状况。

总结

总的来讲，当在剧本内里发出要求时，会有以下状况：

  1. 所要求资本的协定、端口或许域名如果与当前发出要求的页面地点一致，那末则相符同源战略，要求可以被平常发出。反之，则称为跨域要求，须要恪守 CORS 机制。

  2. 一切跨域要求内里，效劳器端必需返回 Access-Control-Allow-Origin 相应头，而且其值与要求中的 Origin 要求头的值相婚配。此时要求才可以被许可，不然要求将会被浏览器阻拦掉。

  3. 跨域要求分为两种，一种是简朴跨域要求，别的一种黑白简朴跨域要求。非简朴跨域要求在发出要求之前，浏览器会先发出一个 preflight 要求，即一个 OPTIONS 要求，用来考证效劳器端是不是许可该要求的接见。当 OPTIONS 要求胜利时，才会继承发送真正的要求。不然要求将会在 OPTIONS 阶段便失利了，后续真正的要求也不会发出去。

  4. 当要求带上了特别的要求头时，效劳器端返回的 OPTIONS 要求的相应必需包含 Access-Control-Allow-Headers 相应头，而且该值包含要求所带上的特别要求头的称号。这时刻要求才会胜利，不然会被浏览器阻拦。

  5. 当要求运用了特别的 HTTP 要领，效劳器端返回的 OPTIONS 要求的相应必需包含 Access-Control-Allow-Methods 相应头，而且该值包含当前运用的 HTTP 要领。如果没有该相应头，或许当前运用的要领并不在其值内里，则要求会被浏览器阻拦。

  6. 因为非简朴要求每次完全要求一次资本现实上都邑发出去两个要求，为了削减 OPTIONS 要求发出的次数，以便削减带宽糟蹋，效劳器端可以设置 Access-Control-Max-Age 来指定浏览器可以在多长时候内对 OPTIONS 要求做缓存，使得一次要求胜利后，下次要求雷同的接口时不必再发出 OPTIONS 要求。

  7. 当跨域要求须要带上 cookie 等身份凭据时，须要手动开启 withCredentials 选项，而且效劳器端须要设置 Access-Control-Allow-Credentials 的相应头，不然要求将不会带上任何身份凭据，或许当没有 Access-Control-Allow-Credentials 时要求会被浏览器阻拦。

  8. 当要求有带上身份凭据时，效劳器端除了须要设置 Access-Control-Allow-Credentials 相应头以外，Access-Control-Allow-Origin 相应头的值不能是通配符，必需是详细的某一个域名。不然会被浏览器阻拦。

在以上 8 点当中，值得注意的是第 3 点和第 8 点。

OPTIONS 要求是一个比较轻易被人疏忽的一个症结点，有一些后端职员在编写接口的时刻，每每只知道在接口的相应头内里写入 Access-Control-Allow-Origin ，而没有意想到 OPTIONS 要求的存在。特别是 OPTIONS 要求并不是每一个跨域要求都邑带上的，这就致使了有些人会有疑问，为何明显我发出去的是 GET 要求，效果倒是发出去了一个 OPTIONS 要求。而纵然有对 OPTIONS 要求做跨域许可的话，那末也很轻易因为缺乏相应的 Access-Control-Allow-Headers 或 Access-Control-Allow-Methods 相应头致使要求依然失利。

第 8 点也是一个异常重要的症结点。如果你有接口须要对多个差别域名的网站供应效劳的话，那末你的接口就不能运用 cookie 等身份凭据了，毕竟 Access-Control-Allow-Origin 不能设置为通配符，限定了接口运用的对象。

彩蛋时候

前面提到了只要非简朴要求才会触发 OPTIONS 要求，而满足简朴要求也就只要那三个前提。然则现实并不是设想中的那末圆满。

如果你运用了 XMLHttpRequest 来完成文件上传的话，如果在 xhr.upload 这个对象内里增加任何事宜监听，就会触发 OPTIONS 要求。纵然此时该要求本身是满足简朴要求的三个前提的。而一旦把事宜监听去掉就没有。详细可以参考 demo-10、 demo-11、 demo-12

这个「bug」是我当初在编写 uploader 这个库时无意间发明的，我当时还以为是浏览器的 bug ，然则厥后在 Stackoverflow 举行一番搜刮后才发明，本来这是浏览器隐蔽的一个 「feature」。。

Turns out this is not a bug. The spec for XMLHttpRequest does mention that upload progress event handlers should cause the “force preflight” flag to be set. I was a bit confused when this was not specifically mentioned in the CORS spec, even though that spec does reference the existence of a “force preflight” flag.

    原文作者：serenader
    原文地址: https://segmentfault.com/a/1190000008456994
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞