我們用apache的HttpClient這個庫消費云端的Restful API時，一般都需要兩次HTTP調(diào)用，第一次獲得某種token，比如獲取防止跨域請求偽造攻擊Cross-site request forgery - CSRF的token，或者比如微信API的access token，第二次再進(jìn)行真正的API消費。

通常情況下，第一次請求完畢后，服務(wù)器都會給客戶端返回一些cookie字段，在第二次請求時，如果使用的是postman測試工具或者apache的HttpClient這個庫，cookie字段都會自動被附加在第二次請求的HTTP頭部。詳情可以參考我寫的另一篇博客：OData service parallel performance measurement – how to deal with XSRF token in Java Program and JMeter
https://blogs.sap.com/2017/08/28/odata-service-parallele-performance-measurement-how-to-deal-with-xsrf-token-in-java-program-and-jmeter/

本文就來介紹apache的HttpClient，在發(fā)送第二個Http請求時，是如何自動插入從第一個請求獲得的服務(wù)器頒發(fā)的cookie的。

首先進(jìn)入HttpClient的單步調(diào)試：InternalHttpClient.doExecute方法：

第85行的origheaders，即取出程序員在代碼里指定的http請求頭部字段，比如basic Authentication，content-type，token等等：

這個cookie是什么時候傳進(jìn)來的？

看來我們必須進(jìn)入httpcore-4.4.3.jar這個apache HttpClient的實現(xiàn)里去調(diào)試。

經(jīng)過觀察發(fā)現(xiàn)，一旦我執(zhí)行完204行的conn.sendRequestHeader方法，就能觀察到Cookie被自動設(shè)置了，所以奧妙就在第204行里。

自動添加Content-Length頭部字段：

由此可見Content-length是通過方法entity.getContentLength()自動計算出來的，因此我們程序員不必在自己的應(yīng)用代碼里重復(fù)這個計算動作。

自動加入host字段：

自動加入Connection: Keep-Alive

UserAgent的自動填充：Apache-HttpClient/4.5.1, 這個也不用程序員操心。

終于到了我要找的RequestAddCookies這個HTTPRequestInterceptor了。光從這個類的字面意思就能猜到它和HTTP請求的Cookie有關(guān)。

新建一個Cookie，這個CookieOrigin構(gòu)造函數(shù)里的hpst，path和secure標(biāo)志位都是Chrome開發(fā)者工具的Cookie標(biāo)簽頁里能看到。

從 Cookie Store里取出前一次請求中由服務(wù)器返回的Cookie：

這里把Cookie store里的cookie加到第二個請求的頭部字段，謎底就這樣解開了。

要獲取更多Jerry的原創(chuàng)文章，請關(guān)注公眾號"汪子熙":

總結(jié)

以上是生活随笔為你收集整理的使用apache的HttpClient进行http通讯，隐藏的HTTP请求头部字段是如何自动被添加的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。