## 奇怪的問題 最近在公司有個系統需要呼叫第三方的一個webservice。本來呼叫一個下很簡單的事情，使用HttpClient構造一個SOAP請求傳送出去拿到XML解析就是了。 可奇怪的是我們的請求在執行一段時間後就會被伺服器504給拒絕掉了。導致系統無法使用，使用者叫苦連天。 古怪就古怪在這個問題不是每次都會出現，是隔三差五的查詢，每次修改完程式碼釋出上去以為好了， 過了兩天又不行了，簡直讓人奔潰。 ## Postman測試 在反覆除錯程式碼無果的情況下，我懷疑是對方伺服器的問題。於是拿出Postman往對方伺服器傳送請求測試。 postman測試一測就測出問題了，不管傳送什麼，伺服器全部給出了504的響應。因為在瀏覽器裡訪問webservice的首頁是可以的，但是為什麼在postman上面就不行了呢？ 於是我開始反覆檢查postman的請求有何不同，到這裡感覺離發現問題不遠了。在反覆檢視下我開始懷疑是postman的一個頭部的問題： ``` Postman-Token: 4d407574-636b-9343-8216-7f2845cbeef1 ``` postman每次傳送請求的時候都會帶上一個叫做postman-token的頭部。於是我把這個頭部給禁用了再試一次，果斷成功了。 在反覆測試下終於明白了，對方伺服器應該有防護，只要http請求裡帶有自定義的頭部就會直接給出504的響應，直接拒絕請求。 至此伺服器拒絕請求的原因終於明瞭了。 ## fiddler監控 但是，我們的程式碼傳送請求的時候並沒有帶上任何自定義的頭部啊。莫非.NET Core會在傳送請求的時候帶上什麼頭部嗎？ 於是在伺服器上安裝fiddler，把請求通過fiddler代理轉發出去，然後監控http請求的頭部。當系統再次出現問題的時候 果斷上去檢視fiddler。一看果然發現了問題，所有被拒絕的請求都帶上了一個叫“Request-Id”的頭部。  當時我是震驚的，.NetCore居然會自說自話給我加上一個頭部？ 如果不是親身發現，打死我也不會相信的。或許你看到這裡也還是不相信，心裡在想一定是我搞錯了吧。 ## Request-Id頭部到底哪裡來的？ 這個問題真是百思不得其解，於是開始請教google。很快在.net core runtime的github上的issues發現一個同樣的問題： [HttpClient automatically adds Request-Id HTTP header](https://github.com/dotnet/runtime/issues/35337) 提問的人說使用HttpClient傳送請求的時候莫名其妙加上了一個Request-Id，跟我情況一毛一樣。 於是乎有人開始討論。有人說HttpClient不可能自己加上Request-Id這個頭部的，下面的老哥直接打臉，說：事實上會的，還給出了原始碼的位置。笑哭！後來還有開發者回覆這個功能是內建的，是為了分散式追蹤。 既然原始碼都給出來了，直接從上面老哥給出的原始碼位置開始追原始碼。下面大概說一下原始碼： HttpClient預設建構函式： ``` public HttpClient() : this(new HttpClientHandler()) { } ``` 繼續看裡面的HttpClientHandler： ``` protected internal overr