摘要:WEBAPI利用System.Web.Http.Cors開啟OPTION,以達到跨網域設定自定義Header
其實本篇只是小弟日前所遇到的小問題.
在此做個記事.
寫的不好或是有誤的地方也請各位前輩多多指導
由於目前小弟的開發環境中,
需要與WEB API 做介接,
所以都會碰到跨網域請求的需求,
例如api.xxxx.com,api2.xxxx.com
但就單以純粹傳送資料至API來說,
SERVER端的API只需要
Access-Control-Allow-Origin
設定指定的網域也或者*號全部接受
如下圖
這樣Client端就能透過Simple requests(簡易請求)取回資料,
但問題來了,如果說我需要使用客製化的header呢?
當然小弟較為笨拙認為照原樣送就好了!
如下圖
結果就是冏了!!
如下圖
出現了405 OPTION Method Not Allowed
當然翻了一下解決方式!
其實很簡單只需要透過System.Web.Http.Cors在允許的動詞指令(methods)中加上OPTION就可以正常了
如下圖
至於更詳細的使用方式請參考
http://www.asp.net/web-api/overview/security/enabling-cross-origin-requests-in-web-api
不過還是有一點點小小疑問,
為什麼在送客製化header的時候,
會自動送出OPTION的請求?
參考了一下mozilla MDN HTTP access control (CORS) 這篇文章中
晃然大悟,也就是在此做個分享
跟上述一開始所說的Simple requests(簡易請求),
在未送任何自定義的header,會自動採取(簡易請求),
但如果是跨網域中你需要傳送自定義的heade那麼就會採用Preflighted requests(預檢/先導請求)
由於跨站請求可能會攜帶使用者資料，所以必須先進行像Server端提出請求先導請求
這時候就會透過XHR第一次送出你想要自定義的header像Server端提出請求(WEB API),
就是採用OPTION
如果成功在Response Header中就會回覆允許自定義的header格式
Access-Control-Allow-Headers: test-a,test-b
如下圖
接下來第二次的請求才是真正的將值接收回來,並確定將自定義的header送出
如下圖
在此處放上範例程式碼:請點我