介紹

CORS 規範定義簡單請求的原則是：並非以「新增」、「修改」、「刪除」為目的，伺服器對請求的處理不會導致自身資料的改變。對於簡單跨域資源請求來說，瀏覽器將兩個步驟（取得授權和獲取資源）合二為一，由於不涉及資源改變，因此沒有副作用。

對於一個請求，必須同時符合以下要求才會被劃分為「簡單請求」：

• Http Method 只為其一：
  • GET
  • POST
  • HEAD
• 請求的 HEAD 只能在以下範圍：
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type

除此之外的請求都為非簡單請求（複雜請求）

非簡單請求可能改變伺服器資源，因此 CORS 規定瀏覽器在發出此類請求前必須有一個「預檢（Preflight）」機制，這也就是我們熟悉的「OPTIONS」請求。

作用

在瀏覽器發出真正的請求前，先發送一個預檢請求，這個在 HTTP 裡就是 OPTIONS 請求方式。此請求比較特殊，不包含主體（無參數、無Body），主要是將憑證、授權相關的輔助訊息放在 HEADER 中交給伺服器做決策。因此它除了攜帶 Origin 請求頭外，還會額外攜帶兩個 HEADER 屬性：

• Access-Control-Request-Method：真正請求的方法
• Access-Control-Request-Headers：真正請求的自定義請求 HEADER，若没有就是空值

伺服器在接收到此請求後，可以根據其值做邏輯決策了。如果允許預檢通過，則返回 200，反則返回 400、403 等等。

如果預檢成功，在 res 中應該抱函上文提到的 HEADER「Access-Control-Allow-Origin」、「Access-Control-Expose-Headers」，除此之外，伺服器還可以做更精細畫的控制，其 res 的 HEADER 為：

• Access-Control-Allow-Methods：允許實際請求的 HTTP 方法
• Access-Control-Allow-Headers：允許實際請求的 HEADER
• Access-Control-Max-Age：允許瀏覽器暫存此結果多久（秒）。有了暫存，之後就不用每次請求都傳送預檢請求了

預檢請求完成後的關鍵點，就是瀏覽器拿到預檢請求響應的處理邏輯，如下：

1. 先通過自己的 origin 匹配預檢響應中「Access-Control-Allow-Origin」的值，若不匹配就结束請求，若匹配就繼續下一步驗證。

   （關於 Access-Control-Allow-Origin 的驗證邏輯，請參考其他文章）

2. 取得預檢響應的「Access-Control-Allow-Methods」。若此標頭不存在，則直接進入下一步，若存在驗證正式請求的方法是否存於「Access-Control-Request-Method」的值是否在此列表中，在内繼續下一步，否則失敗。