爲什麼同一個ajax調用有不同的請求頭文件？

Question

對於相同的調用和來自同一瀏覽器的相同JS代碼，請求標頭如何可能不同？

我有一個Web API項目，我打電話給這個API的方法來自兩個不同的項目（CORS calls），使用$http.get方法AngularJs 1.X。

$http.get("http://local.api:9002/api/default/get") 
    .then(function success(response, status, headers, config) { 
      console.info(response); 
      }, 
      function error(response, status, headers, config) { 
      console.info(response); 
      } 
     ); 

這是從兩個前端UI用來調用API的代碼。

但是，對於其中一個調用成功，另一個失敗，指出以下錯誤。

對預檢請求的響應未通過訪問控制檢查：請求的資源上沒有「Access-Control-Allow-Origin」標頭。

經過觀察，我發現兩個調用的請求標頭有所不同。

請求標頭調用成功 - AngularJS v1.6.4

Accept:application/json, text/plain, */* 
Accept-Encoding:gzip, deflate, sdch 
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6 
Connection:keep-alive 
Host:local.api:9002 
Origin:http://local.ui.one:9001 
Referer:http://local.ui.one:9001/ 
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 

響應頭爲成功

Access-Control-Allow-Origin:http://local.ui.one:9001 
Cache-Control:no-cache 
Content-Length:19 
Content-Type:application/json; charset=utf-8 
Date:Fri, 05 May 2017 01:05:05 GMT 
Expires:-1 
Pragma:no-cache 
Server:Microsoft-IIS/7.5 
X-AspNet-Version:4.0.30319 
X-Powered-By:ASP.NET 

請求頭呼叫失敗通話 - AngularJS v1.2.17

爲呼叫失敗

Cache-Control:no-cache 
Content-Length:113 
Content-Type:application/json; charset=utf-8 
Date:Fri, 05 May 2017 01:22:14 GMT 
Expires:-1 
Pragma:no-cache 
Server:Microsoft-IIS/7.5 
X-AspNet-Version:4.0.30319 
X-Powered-By:ASP.NET 

這些

響應頭是兩個請求頭是在第二呼叫附加。

Access-Control-Request-Headers:cache-control,if-modified-since,pragma,x-requested-with 
Access-Control-Request-Method:GET 

注：

1. 我的UI一個和API都在同一Visual Studio Solution，而UI二是在不同的Solution。我相信這不是原因，但我可能是錯的。
2. 我在這兩個UI項目中都有不同的AngularJS版本。這可能是一個可能的原因嗎？

編輯

至於建議的@Phil，我更新了我的後臺API來處理從我的第二UI項目未來的預檢要求。

public static class WebApiConfig 
{ 
    public static void Register(HttpConfiguration config) 
    { 
     //Some API routes here... 

     var enableCorsAttribute = new EnableCorsAttribute(
      // Comma separated whitelist of allowed domains, notice no slash ('/') at the end of domain 
      "http://local.ui.two:9003,http://local.ui.one:9001", 
      // Allowed Custom Headers 
      "Origin, X-Requested-With, Content-Type, Accept, Authorization, Cache-Control, If-Modified-Since, Pragma", 
      // Allowed methods 
      "GET, PUT, POST, DELETE, OPTIONS" 
     ); 

     config.EnableCors(enableCorsAttribute); 
    } 
} 

並在Global.asax註冊了此WebApiConfig。

protected void Application_Start() 
{ 
    GlobalConfiguration.Configure(WebApiConfig.Register); 
} 

而且它也開始處理來自第二UI項目的調用，儘管請求標頭不同。

Answer 1

對於呼叫失敗 - AngularJS v1.2.17

Access-Control-Request-Headers:cache-control,if-modified-since,pragma,x-requested-with 
Access-Control-Request-Method:GET 

這對我來說看起來就像瀏覽器做了CORS pre-flight check獲得許可，包括非標頭。查看應用程序，看看爲什麼要添加這些非標準標題。

v1.1.1之前版本的AngularJS用於包含x-request-with作爲默認值並導致此問題。

檢查更改爲$httpProvider.defaults的配置塊。

有關允許的頭，將不會觸發飛行前要求的列表，請參閱MDN HTTP Reference - Access_control_CORS (Simple Requests)

Answer 2

這是我的猜測......

老版本的角度增加了x-requested-with頭。這已經被放棄了。此標題會導致您的CORS請求爲non-simple，這會觸發請求前的OPTIONS請求。看起來你的後端沒有設置來處理這些請求。

可以解決這個在舊角版本通過在config功能刪除頁眉

delete $httpProvider.defaults.headers.common['X-Requested-With']; 

的關鍵是這一行什麼，我認爲是對OPTIONS要求

請求頭

訪問控制請求頭：高速緩存控制如果修改以來編譯指示x請求與

---

如果您希望API能夠正確處理跨源請求，它應該能夠正確響應請求前的OPTIONS請求。