摘要：常用跨域方法總結上篇文章介紹了幾種常用的跨域方法常用跨域方法總結，本片為上一篇的補充，對比較重要的詳細介紹。出于安全原因，從腳本內發起的跨源請求會受到一定限制。當開發者使用對象發起跨域請求時，它們已經被設置就緒。

上篇文章介紹了幾種常用的跨域方法：常用跨域方法總結，本片為上一篇的補充，對比較重要的Cross Origin Resource Sharing詳細介紹。

出于安全原因，從腳本內發起的跨源HTTP請求會受到一定限制。 例如，XMLHttpRequest和Fetch API遵循同源策略。 這意味著使用這些API的Web應用程序只能從加載應用程序的同一個域請求HTTP資源，除非使用CORS頭文件。
跨域資源共享標準新增了一組 HTTP 首部字段，允許服務器聲明哪些源站有權限訪問哪些資源。另外，規范要求，對那些可能對服務器數據產生副作用的 HTTP 請求方法（特別是 GET 以外的 HTTP 請求，或者搭配某些 MIME 類型的 POST 請求），瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（preflight request），從而獲知服務端是否允許該跨域請求。服務器確認允許之后，才發起實際的 HTTP 請求。在預檢請求的返回中，服務器端也可以通知客戶端，是否需要攜帶身份憑證（包括 Cookies 和 HTTP 認證相關數據）。

若要利用CORS來進行跨域獲取資源，還需要服務端的配合。
這里分為兩種場景：簡單請求和非簡單請求

什么樣的請求才屬于簡單請求呢，讓我們先來看MDN的一段定義

必須使用下列方法中的一種：

GET

HEAD

POST

請求首部字段不能超出以下幾種

Accept

Accept-Language

Content-Language

Content-Type （需要注意額外的限制）

DPR

Downlink

Save-Data

Viewport-Width

Width

Content-Type 的值僅限于下列三者之一：

text/plain

multipart/form-data

application/x-www-form-urlencoded

請求中的任意XMLHttpRequestUpload 對象均沒有注冊任何事件監聽器；XMLHttpRequestUpload 對象可以使用 XMLHttpRequest.upload 屬性訪問。

請求中沒有使用 ReadableStream 對象。

同時滿足以上5種條件，則可以視為簡單請求。
先跑例子吧。
首先上服務端代碼：

var http = require("http");
http.createServer(function (req, res) {
  res.setHeader("Access-Control-Allow-Origin","*");
  res.end(JSON.stringify({"success":true,msg:"今天，我就是要用cors來跨域"+Math.random()}));
}).listen(8080)

很簡單有沒有，
Access-Control-Allow-Origin:限制發起跨域請求的來源，*表示不限制
（請求首部字段下文詳細介紹）
前端代碼：

結果肯定是請求成功啦

簡單來說吧，不符合簡單請求的都是非簡單請求（怎么感覺這么大白話呢- -）詳見CORS

與前述簡單請求不同，“非簡單請求”要求必須首先使用 OPTIONS   方法發起一個預檢請求到服務器，以獲知服務器是否允許該實際請求。"預檢請求“的使用，可以避免跨域請求對服務器的用戶數據產生未預期的影響。

還是先上代碼
服務端：

var http = require("http");
http.createServer(function (req, res) {
  res.setHeader("Access-Control-Allow-Origin","*");
  res.setHeader("Access-Control-Allow-Headers", "Content-Type");
  res.setHeader("Access-Control-Allow-Methods","PUT,GET,POST,DELETE,OPTIONS");
  res.end(JSON.stringify({"success":true,msg:"今天，我就是要用cors來跨域"+Math.random()}));
}).listen(8080)
console.log("正在監聽8080")

Access-Control-Allow-Headers::預檢請求響應的首部字段定義了實際請求中允許攜帶的額外的首部字段。
Access-Control-Allow-Methods:預檢請求響應的首部字段定義了實際請求所允許使用的 HTTP 方法。（筆者做實驗的遇到了一個小插曲，simple method會不受此限制，詳見為什么 Access-Control-Allow-Methods 不起作用？）
前端

結果肯定也是請求成功啦。

這里有一點要注意的地方，這里還是說一下吧

一般而言，對于跨域 XMLHttpRequest 或 Fetch 請求，瀏覽器不會發送身份憑證信息。如果要發送憑證信息，需要設置 XMLHttpRequest 的某個特殊標志位。

也就是前端請求的時候：xhr.withCredentials = true

對于附帶身份憑證的請求，服務器不得設置 Access-Control-Allow-Origin 的值為“”。若請求的首部中攜帶了 Cookie 信息，如果 Access-Control-Allow-Origin 的值為“”，請求將會失敗。

這塊內容MDN已經很詳細了，為了方便閱讀，筆者還是整理過來了。

請注意，這些首部字段無須手動設置。 當開發者使用 XMLHttpRequest 對象發起跨域請求時，它們已經被設置就緒。
Origin首部字段表明預檢請求或實際請求的源站。(注意，不管是否為跨域請求，ORIGIN 字段總是被發送。)
Access-Control-Request-Method,用于預檢請求,表示實際請求的方法
Access-Control-Request-Headers,用于預檢請求,表示實際請求中添加的額外的首部字段

Access-Control-Allow-Method,預檢請求的響應，表示允許的接下來的實際請求的方法。（筆者做實驗的遇到了一個小插曲，simple method會不受此限制，詳見為什么 Access-Control-Allow-Methods 不起作用？）
Access-Control-Allow-Origin,指定了允許訪問該資源的外域 URI。對于不需要攜帶身份憑證的請求，服務器可以指定該字段的值為通配符，表示允許來自所有域的請求。
Access-Control-Allow-Credentials,當瀏覽器(比如xhr)的credentials設置為true時是否允許瀏覽器讀取response的內容。當用在對preflight預檢測請求的響應中時，它指定了實際的請求是否可以使用credentials(如果請求credentials為true時，該響應首部字段需要設置為true)。
Access-Control-Allow-Headers,預檢請求的響應，表示允許的接下來的實際請求的額外的首部字段。預檢請求的響應。其指明了實際請求中允許攜帶的首部字段。
Access-Control-Expose-Headers,在跨域訪問時，XMLHttpRequest對象的getResponseHeader()方法只能拿到一些最基本的響應頭，Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，如果要訪問其他頭，則需要服務器設置本響應頭。
Access-Control-Max-Age:指定了預檢請求的結果能夠被緩存多久

到這里筆者對跨域算是比較熟悉了，感謝各位的閱讀，如有不對的地方，歡迎大家批評指正。
還有，最好是對每個例子都有實際運行理解更深刻哦。

HTTP訪問控制（CORS）