我想我對 CORS 的理解非常好，但是當涉及到預檢請求時，我仍然對瀏覽器的行為感到有些困惑。
假設瀏覽器發出這個預檢請求：
OPTIONS http://myserver.local:7000/api/order/4 HTTP/1.1
Host: myserver.local:7000
Connection: keep-alive
Accept: */*
Access-Control-Request-Method: POST
Access-Control-Request-Headers: x-my-custom-header
Origin: http://localhost:5000
Sec-Fetch-Mode: cors
Referer: http://localhost:5000/
我的 API 回傳：
HTTP/1.1 204 No Content
Date: Wed, 09 Mar 2022 12:52:50 GMT
Server: Kestrel
Access-Control-Allow-Headers: x-my-custom-header
Access-Control-Allow-Methods: PUT,DELETE
Access-Control-Allow-Origin: http://localhost:5000
Vary: Origin
請注意，服務器允許方法PUT和DELETE在對預檢請求的回應中，但不允許POST，這是實際 CORS 請求的方法。
由于實際請求的方法與標頭中列出的方法不匹配，瀏覽器是否應該阻止該請求Access-Control-Allow-Methods？或者服務器用20x狀態碼回應瀏覽器接受預檢然后發送實際請求就足夠了嗎？
我的假設是，如果請求的方法不匹配，瀏覽器會比較允許方法并阻止請求......我錯過了什么嗎？
uj5u.com熱心網友回復：
一個有趣的問題！
TL;博士
不，瀏覽器不需要服務器明確允許該POST方法，因為后者，作為所謂的CORS 安全串列方法，可以獲得免費通行證。
更多細節
規格說明了什么
與往常一樣，答案在于 Fetch 標準（第 4.8 節），它指定了 CORS 的作業方式：
- 讓方法是提取給定的標頭串列值
Access-Control-Allow-Methods和回應的標頭串列的結果。
再往下：
- 如果 request 的方法不在methods中，request的方法不是 CORS 安全串列中的方法，并且 request 的憑證模式是
"include"或方法不包含*，則回傳網路錯誤。
（我的重點）
什么是CORS 安全串列方法？該術語在第 2.2.1 節中定義：
CORS-safelisted 方法是一種方法，即
GET、HEAD或POST。
結論
如果 CORS 請求的方法是、 或之一GET，則瀏覽器不需要服務器在標頭中顯式列出該方法以使 CORS 預檢成功。HEADPOSTAccess-Control-Allow-Methods
實驗
我發現Jake Archibald的CORS 游樂場對于測驗我對 CORS 的（錯誤）理解很有用。在您的瀏覽器中運行此特定實體可能會讓您相信，該POST方法不需要顯式允許 CORS 預檢成功。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/442886.html