共计 1209 个字符，预计需要花费 4 分钟才能阅读完成。
我们用 apache 的 HttpClient 这个库消费云端的 Restful API 时，一般都需要两次 HTTP 调用，第一次获得某种 token，比如获取防止跨域请求伪造攻击 Cross-site request forgery – CSRF 的 token，或者比如微信 API 的 access token，第二次再进行真正的 API 消费。
通常情况下，第一次请求完毕后，服务器都会给客户端返回一些 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…
本文就来介绍 apache 的 HttpClient，在发送第二个 Http 请求时，是如何自动插入从第一个请求获得的服务器颁发的 cookie 的。
首先进入 HttpClient 的单步调试：InternalHttpClient.doExecute 方法：
第 85 行的 origheaders，即取出程序员在代码里指定的 http 请求头部字段，比如 basic Authentication，content-type，token 等等：
这个 cookie 是什么时候传进来的？
看来我们必须进入 httpcore-4.4.3.jar 这个 apache HttpClient 的实现里去调试。
经过观察发现，一旦我执行完 204 行的 conn.sendRequestHeader 方法，就能观察到 Cookie 被自动设置了，所以奥妙就在第 204 行里。
自动添加 Content-Length 头部字段：
由此可见 Content-length 是通过方法 entity.getContentLength() 自动计算出来的，因此我们程序员不必在自己的应用代码里重复这个计算动作。
自动加入 host 字段：
自动加入 Connection: Keep-Alive
UserAgent 的自动填充：Apache-HttpClient/4.5.1, 这个也不用程序员操心。
终于到了我要找的 RequestAddCookies 这个 HTTPRequestInterceptor 了。光从这个类的字面意思就能猜到它和 HTTP 请求的 Cookie 有关。
新建一个 Cookie，这个 CookieOrigin 构造函数里的 hpst，path 和 secure 标志位都是 Chrome 开发者工具的 Cookie 标签页里能看到。
从 Cookie Store 里取出前一次请求中由服务器返回的 Cookie：
这里把 Cookie store 里的 cookie 加到第二个请求的头部字段，谜底就这样解开了。
要获取更多 Jerry 的原创文章，请关注公众号 ” 汪子熙 ”:
