在預設情況下這兩個網域名稱屬於兩個不同的域，他們之間的互動存在跨域的問題，但因為他們都同屬於乙個二級網域名稱下，所以通過簡單的設定就能實現跨域行為，但是考慮到實際生產環境中往往會出現兩個網域名稱
完全不同的情況，所以這裡不考慮這種特殊的情況，使用更通用的方法來解決跨域的問題。
首先在webapi上有如下所示乙個介面
我們需要在我們的web站點下通過ajax方式呼叫這個介面
此時我們可以看到如下的結果
通過分析上述的監視結果可以看到，這個ajax請求是成功的，但是因為響應頭中沒有告訴瀏覽器這個介面可以跨訪問，瀏覽器就拒絕了將請求結果返回給使用者。
通過在action上進行斷點，也可以看出，伺服器已經收到請求並成功執行了
甚至瀏覽器本身也已經接收到了響應結果，因為跨域問題所以拒絕返回給使用者
所以根據上述的錯誤提示，我們很容易就能解決跨域這個問題，就是需要在響應頭中新增access-control-allow-origin
這個響應資料。在iis中我們可以在配置檔案中直接配置這個響應頭，讓所有
的請求都能返回這個響應頭，當然也可以使用**對需要的介面進行單獨返回相應的響應頭，下面是web.config的配置
通過配置上述的配置，指定access-control-allow-origin
響應頭的值返回「*」，則表示任何網域名稱都可以訪問這個webapi
此時再次訪問，可以看到訪問成功，並輸出了返回結果
在實際應用中，我們可能需要手動設定一些請求頭髮送給webapi伺服器，如下所示
此時再次訪問webapi可以看到不一樣的情況
從上圖看到，這個請求不僅僅被終止了，而且不是以我們期望的post方式進行請求的，而是使用了options的方式。
了解http協議的同學可能會知道，options方法只是對伺服器的乙個探測，不會返回相應體。
這裡就是瀏覽器對於跨域傳送自定義請求頭的乙個限制，如果請求跨域並且手動設定了請求頭，那麼瀏覽器會發起兩次請求，一次是options的預檢，詢問伺服器是否支援當前這個比較敏感的操作，如果伺服器返回了期望的響應頭資料，那麼瀏覽器才會正在發起我們的請求。
通過上處分析，web**要能事先跨站傳送請求頭，伺服器必須支援options的預檢，所以這裡必須提供伺服器的實現。
在微軟的webapi框架中我們可以使用microsoft
.aspnet
.webapi
.cors
這個元件來提供支援。
使用nuget進行安裝
安裝完畢後再webapi上對其進行註冊
註冊完畢，最後我們只需要在我們需要跨域的action使用特性就可以支援options預檢，進行跨域請求了
再次請求webapi，我們可能發現請求並不是很成功，不過在ie瀏覽器下，除錯工具給了我們很好的錯誤提醒。
從上圖看到，在options的預檢的響應頭中返回了兩個access-control-allow-origin
響應頭，瀏覽器提示不允許這樣的結果。
仔細回想一下上述的操作可以發現這個響應頭其實是我們自己在webconfig中指派伺服器自動傳送了，這邊的操作與之前的配置產生了衝突，刪除剛才在webconfig
中的配置節點即可
刪除上述的節點後，再次請求伺服器，可以發現正常返回結果了
在上述請求中，瀏覽器發起了一下options預檢與真正的post請求。
有時候需要跨域向webapi傳遞cookie等資訊，此時我們可能看到這裡雖然成功向瀏覽器寫入了cookie，但是瀏覽器並不會主動傳送cookie到伺服器
如果需要接收到cookie資訊，則需要設定supportscredentials屬性為true
瀏覽器跨域訪問WebApi
在預設情況下這兩個網域名稱屬於兩個不同的域，他們之間的互動存在跨域的問題，但因為他們都同屬於乙個二級網域名稱下，所以通過簡單的設定就能實現跨域行為，但是考慮到實際生產環境中往往會出現兩個網域名稱 完全不同的情況，所以這裡不考慮這種特殊的情況，使用更通用的方法來解決跨域的問題。首先在webapi上有如...
瀏覽器訪問跨域問題
專案中遇到乙個問題 用ajax來獲取資料，但返回的status為0，從瀏覽器的列印看應該是跨域問題 origin file has been blocked by cors policy response to preflight request does not pass access contr...
瀏覽器跨域
前端部分，簡單的封裝乙個promise版的ajax let myajax function headers else xhr.open method,path for let key,value of object.entries headers xhr.send body myajax heade...