理解 CORS：簡單請求與預檢請求

前言

前兩篇文章分別記錄 Instagram fetch 和 IIS OPTIONS 的問題，這篇整理 CORS 的基本規則。

W3C 的 CORS 規範不只定義瀏覽器如何處理跨來源請求，也規範伺服器可以控制的項目，包括允許的來源、請求方法、Cookie、可讀取的回應標頭與回應有效期限。

CORS 相關 HTTP Header

CORS
- Access-Control-Allow-Origin：
  - 伺服器收到跨來源請求時，會在 Response 加上這個 Header 指定允許的來源；若允許任何來源，則使用 * 號
- Access-Control-Allow-Credentials：
  - 值為 True 或 False，決定跨來源請求的 Response 是否能包含 Cookie 等憑證資訊。
- Access-Control-Allow-Headers：
  - 回應預檢請求時，列出實際請求可使用的 HTTP Header。
- Access-Control-Allow-Methods：
  - 回應預檢請求時，列出允許存取資源的 HTTP 方法。
- Access-Control-Expose-Headers：
  - 列出允許 JavaScript 讀取的 Response Header。
- Access-Control-Max-Age：
  - 指定預檢結果可快取的時間。
- Access-Control-Request-Headers：
  - 在發出預檢請求時使用，讓伺服器知道實際請求會使用哪些 HTTP Header。
- Access-Control-Request-Method：
  - 在發出預檢請求時使用，讓伺服器知道實際請求會使用哪一種 HTTP 方法。
- Origin：指出請求的來源。

CORS 將跨來源請求分為簡單請求（Simple Request）與預檢請求（Preflight Request）

簡單請求

方法只能是HEAD、GET、POST
可用標頭Accept、Accept-Language、Content-Language、Last-Event-ID，以及Content-Type
Content-Type也只允許三個值application/x-www-form-urlencoded、multipart/form-data、text/plain

預檢請求

預檢分成兩步。第一步以 HTTP OPTIONS 方法送出，並帶有兩個 Request Header：Access-Control-Request-Method 和 Access-Control-Request-Headers。OPTIONS 成功後，瀏覽器才會送出實際請求。

fetch API 的 no-cors 問題

引用文章：

很多人會認為只要將 fetch 裡的屬性 mode，調整成 mode: 'no-cors'，就可以避免 CORS，其實不是！

mode: 'no-cors 在設定上的意義是，告訴瀏覽器，我本來就知道 server 對於這個 request 是沒有設定可以存取 CORS 的，我本來就拿不到 response，我設定mode: 'no-cors，是為了，就算無法存取，也不要跑到 .catch() 那邊，讓它出現 Error。

一樣拿不到 server 的 response，但會拿到一個 status: 0 的 response。

結論：在 CORS 限制下，只有伺服器允許跨來源存取，瀏覽器端才能取得 response；設定 no-cors 並不會解除限制。

參考：

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers