Cross-origin Resource Sharing 中文名稱 “跨域資源共享” 簡稱 “CORS”，它突破了一個請求在瀏覽器發出只能在同源的情況下向服務器獲取數據的限制。
本文會先從一個示例開始，分析是瀏覽器還是服務器的限制，之后講解什么時候會產生預檢請求，在整個過程中，也會講解一下解決該問題的實現方法，文末會再總結如何使用 Node.js 中的 cors 模塊和 Nginx 反向代理來解決跨域問題。
文中使用 Node.js 做一些 Demo 的演示，每一小節之后也會給予代碼的 Demo 地址。
瀏覽器還是服務器的限制
先思考下，CORS 是瀏覽器端還是服務器端的限制?為了更好的說明這個問題，從一段示例開始。
1. 從一段示例開始
(1) index.html
創建 index.html 使用 fetch 調用 http://127.0.0.1:3011/api/data
<body>
<!-- <script src="https://cdn.bootcdn.net/ajax/libs/fetch/3.0.0/fetch.min.js"></script> -->
<script>
fetch('http://127.0.0.1:3011/api/data');
</script>
</body>
(2) client.js
創建 client.js 用來加載上面 index.html。設置端口為 3010。
const http = require('http');
const fs = require('fs');
const PORT = 3010;
http.createServer((req, res) => {
fs.createReadStream('index.html').pipe(res);
}).listen(PORT);
(3) server.js
創建 server.js 開啟一個服務，根據不同的請求返回不同的響應。設置端口為 3011。
const http = require('http');
const PORT = 3011;
http.createServer((req, res) => {
const url = req.url;
console.log('request url: ', url);
if (url === '/api/data') {
return res.end('ok!');
}
if (url === '/script') {
return res.end('console.log("hello world!");');
}
}).listen(PORT);
console.log('Server listening on port ', PORT);
2. 測試分析原因
運行上面的 client.js、server.js 瀏覽器輸入 http://127.0.0.1:3010 在 Chrome 瀏覽器中打開 Network 項查看請求信息，如下所示：
左側是使用 fetch 請求的 127.0.0.1:3011/api/data 接口，在請求頭里可以看到有 Origin 字段，顯示了我們當前的請求信息。另外還有三個 Sec-Fetch-* 開頭的字段，這是一個新的草案 Fetch Metadata Request Headers[1]。
其中 Sec-Fetch-Mode 表示請求的模式，通過左右兩側結果對比也可以看出左側是跨域的。Sec-Fetch-Site 表示的是這個請求是同源還是跨域，由于我們這兩個請求都是由 3010 端口發出去請求 3011 端口，是不符合同源策略的。
看下瀏覽器 Console 下的日志信息，根據提示得知原因是從 “http://127.0.0.1:3010” 訪問 “http://127.0.0.1:3011/api/data” 被 CORS 策略阻止了，沒有 “Access-Control-Allow-Origin” 標頭。
在看下服務端的日志，因為請求 3011 服務，所以就看下 3011 服務的日志信息：
Server listening on port 3011
request url: /script
request url: /api/data
在服務端是有收到請求信息的，說明服務端是正常工作的。
我們也可以在終端通過 curl 命令測試下，在終端脫離瀏覽器環境也是可以正常請求的。
$ curl http://127.0.0.1:3011/api/data
ok!
本節代碼示例：
github.com/qufei1993/http-protocol/tree/master/example/cors/01
3. 總結回答最開始提出的問題
瀏覽器限制了從腳本內發起的跨源 HTTP 請求，例如 XMLHttpRequest 和我們本示例中使用的 Fetch API 都是遵循的同源策略。
當一個請求在瀏覽器端發送出去后，服務端是會收到的并且也會處理和響應，只不過瀏覽器在解析這個請求的響應之后，發現不屬于瀏覽器的同源策略(地址里面的協議、域名和端口號均相同)也沒有包含正確的 CORS 響應頭，返回結果被瀏覽器給攔截了。
預檢請求
預檢請求是在發送實際的請求之前，客戶端會先發送一個 OPTIONS 方法的請求向服務器確認，如果通過之后，瀏覽器才會發起真正的請求，這樣可以避免跨域請求對服務器的用戶數據造成影響。
看到這里你可能有疑問為什么上面的示例沒有預檢請求?因為 CORS 將請求分為了兩類：簡單請求和非簡單請求。我們上面的情況屬于簡單請求，所以也就沒有了預檢請求。
讓我們繼續在看下簡單請求和非簡單請求是如何定義的。
1. 預檢請求定義
根據 MDN 的文檔定義，請求方法為：GET、POST、HEAD，請求頭 Content-Type 為：text/plain、multipart/form-data、application/x-www-form-urlencoded 的就屬于 “簡單請求” 不會觸發 CORS 預檢請求。
例如，如果請求頭的 Content-Type 為 application/json 就會觸發 CORS 預檢請求，這里也會稱為 “非簡單請求”。
“MDN 文檔 developer.mozilla.org/en-US/docs/Web/HTTP/CORS 簡單請求”[2] 有更多關于簡單請求的字段定義。
2. 預檢請求示例
通過一個示例學習下預檢請求。
3. 設置客戶端
為 index.html 里的 fetch 方法增加一些設置，設置請求的方法為 PUT，請求頭增加一個自定義字段 Test-Cors。
<script>
fetch('http://127.0.0.1:3011/api/data', {
method: 'PUT',
headers: {
'Content-Type': 'text/plain',
'Test-Cors': 'abc'
}
});
</script>
上述代碼在瀏覽器執行時會發現是一個非簡單請求，就會先執行一個預檢請求，Request Headers 會有如下信息：
OPTIONS /api/data HTTP/1.1
Host: 127.0.0.1:3011
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: content-type,test-cors
Origin: http://127.0.0.1:3010
Sec-Fetch-Mode: cors
可以看到有一個 OPTIONS 是預檢請求使用的方法，該方法是在 HTTP/1.1 協議中所定義的，還有一個重要的字段 Origin 表示請求來自哪個源，服務端則可以根據這個字段判斷是否是合法的請求源，例如 Websocket 中因為沒有了同源策略限制，服務端可以根據這個字段來判斷。
Access-Control-Request-Method 告訴服務器，實際請求將使用 PUT 方法。
Access-Control-Request-Headers 告訴服務器，實際請求將使用兩個頭部字段 content-type,test-cors。這里如果 content-type 指定的為簡單請求中的幾個值，Access-Control-Request-Headers 在告訴服務器時，實際請求將只有 test-cors 這一個頭部字段。
4. 設置服務端
上面講解了客戶端的設置，同樣的要使請求能夠正常響應，還需服務端的支持。
修改我們的 server.js 重點是設置 Response Headers 代碼如下所示：
res.writeHead(200, {
'Access-Control-Allow-Origin': 'http://127.0.0.1:3010',
'Access-Control-Allow-Headers': 'Test-CORS, Content-Type',
'Access-Control-Allow-Methods': 'PUT,DELETE',
'Access-Control-Max-Age': 86400
});
為什么是以上配置?首先預檢請求時，瀏覽器給了服務器幾個重要的信息 Origin、Method 為 PUT、Headers 為 content-type,test-cors 服務端在收到之后，也要做些設置，給予回應。
Access-Control-Allow-Origin 表示 “http://127.0.0.1:3010” 這個請求源是可以訪問的，該字段也可以設置為 “*” 表示允許任意跨源請求。
Access-Control-Allow-Methods 表示服務器允許客戶端使用 PUT、DELETE 方法發起請求，可以一次設置多個，表示服務器所支持的所有跨域方法，而不單是當前請求那個方法，這樣好處是為了避免多次預檢請求。
Access-Control-Allow-Headers 表示服務器允許請求中攜帶 Test-CORS、Content-Type 字段，也可以設置多個。
Access-Control-Max-Age 表示該響應的有效期，單位為秒。在有效時間內，瀏覽器無須為同一請求再次發起預檢請求。還有一點需要注意，該值要小于瀏覽器自身維護的最大有效時間，否則是無效的。
看下增加了預檢請求的效果，第一次先發出了 OPTIONS 請求，并且在請求頭設置了本次請求的方法和 Headers 信息，服務端在 Response 也做了回應，在 OPTIONS 成功之后，瀏覽器緊跟著才發起了我們本次需要的真實請求，如圖右側所示 Resquest Method 為 PUT。
本節代碼示例：github.com/qufei1993/http-protocol/tree/master/example/cors/02
CORS 與認證
對于跨域的 XMLHttpRequest 或 Fetch 請求，瀏覽器是不會發送身份憑證信息的。例如我們要在跨域請求中發送 Cookie 信息，就要做些設置：
為了能看到效果，我先自定義了一個 cookie 信息 id=NodejsRoadmap。
重點是設置認證字段，本文中 fetch 示例設置 credentials: "include" 如果是 XMLHttpRequest 則設置 withCredentials:"include"
<body>
<script>
document.cookie = `id=NodejsRoadmap`;
fetch('http://127.0.0.1:3011/api/data', {
method: 'PUT',
headers: {
'Content-Type': 'application/json',
'Test-Cors': 'abc',
},
credentials: "include"
});
</script>
</body>
經過以上設置，瀏覽器發送實際請求時會向服務器發送 Cookies，同時服務器也需要在響應中設置 Access-Control-Allow-Credentials 響應頭
res.writeHead(200, {
'Access-Control-Allow-Origin': 'http://127.0.0.1:3010',
'Access-Control-Allow-Credentials': true
});
如果服務端不設置瀏覽器就不會正常響應，會報一個跨域錯誤，如下所示：
Access to fetch at 'http://127.0.0.1:3011/api/data' from origin 'http://127.0.0.1:3010' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'.
還有一點需要注意，如果我們在請求中設置了 credentials: "include" 服務端就不能設置 Access-Control-Allow-Origin: "*" 只能設置為一個明確的地址。
本節代碼示例：github.com/qufei1993/http-protocol/tree/master/example/cors/03
解決跨域問題的幾種方法
通過上面的分析了解跨域產生的原因之后，解決其實并不難，上面的講解中其實也提供了解決方案，例如在 Node.js 中我們可以設置響應頭部字段 Access-Control-Allow-Origin、Access-Control-Expose-Headers、Access-Control-Allow-Methods 等，但是在實際開發中這樣設置難免繁瑣，下面介紹幾種常用的解決方法。
1. 使用 CORS 模塊
在 Node.js 中推薦你使用 cors 模塊 github.com/expressjs/cors[3]。
在我們本節的示例中，一直使用的 Node.js 原生模塊來編寫我們的示例，在引入 cors 模塊后，可以按照如下方式改寫：
const http = require('http');
const PORT = 3011;
const corsMiddleware = require('cors')({
origin: 'http://127.0.0.1:3010',
methods: 'PUT,DELETE',
allowedHeaders: 'Test-CORS, Content-Type',
maxAge: 1728000,
credentials: true,
});
http.createServer((req, res) => {
const { url, method } = req;
console.log('request url:', url, ', request method:', method);
const nextFn = () => {
if (method === 'PUT' && url === '/api/data') {
return res.end('ok!');
}
return res.end();
}
corsMiddleware(req, res, nextFn);
}).listen(PORT);
cors 在預檢請求之后或在預檢請求里并選項中設置了 preflightContinue 屬性之后才會執行 nextFn 這個函數，如果預檢失敗就不會執行 nextFn 函數。
如果你用的 Express.js 框架，使用起來也很簡單，如下所示：
const express = require('express')
const cors = require('cors')
const app = express()
app.use(cors());
2. JSONP
瀏覽器是允許像 link、img、script 標簽在路徑上加載一些內容進行請求，是允許跨域的，那么 jsonp 的實現原理就是在 script 標簽里面加載了一個鏈接，去訪問服務器的某個請求，返回內容。
<body>
<script>
// fetch('http://127.0.0.1:3011/api/data', {
// method: 'PUT',
// headers: {
// 'Content-Type': 'application/json',
// 'Test-Cors': 'abc',
// },
// credentials: "include"
// });
<srcipt src="http://127.0.0.1:3011/api/data"></srcipt>
</script>
</body>
相比上面 CORS 模塊，JSONP 只支持 GET 請求，顯然是沒有 CORS 模塊強大的。
3. Nginx 代理服務器配置跨域
使用 Nginx 代理服務器之后，請求不會直接到達我們的 Node.js 服務器端，請求會先經過 Nginx 在設置一些跨域等信息之后再由 Nginx 轉發到我們的 Node.js 服務端，所以這個時候我們的 Nginx 服務器去監聽的 3011 端口，我們把 Node.js 服務的端口修改為 30011，簡單配置如下所示：
server {
listen 3011;
server_name localhost;
location / {
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' 'http://127.0.0.1:3010';
add_header 'Access-Control-Allow-Methods' 'PUT,DELETE';
add_header 'Access-Control-Allow-Headers' 'Test-CORS, Content-Type';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Content-Length' 0;
return 204;
}
add_header 'Access-Control-Allow-Origin' 'http://127.0.0.1:3010';
add_header 'Access-Control-Allow-Credentials' 'true';
proxy_pass http://127.0.0.1:30011;
proxy_set_header Host $host;
}
}
本節代碼示例：github.com/qufei1993/http-protocol/tree/master/example/cors/04
總結：
如果你是一個前端開發者，在工作難免會遇到跨域問題，雖然它屬于瀏覽器的同源策略限制，但是要想解決這問題還需瀏覽器端與服務端的共同支持，希望讀到這篇文章的讀者能夠理解跨域產生的原因，最后給予的幾個解決方案，也希望能解決你對于跨域這個問題的困惑。
