说明
本文存在的原因，是想深入的学习下HttpClient。对应的网址是：
http://hc.apache.org/httpcomponents-client-4.5.x/primer.html
http://hc.apache.org/httpcomponents-client-4.5.x/tutorial/html/index.html
如果想学习怎么使用HttpClient，建议直接看官方给的例子：
http://hc.apache.org/httpcomponents-client-4.5.x/quickstart.html
简介
客户端HTTP编程入门，英文又叫 Client HTTP Programming Primer ，是专门针对缺少HTTP相关知识的人而准备的。注意，它仅仅是帮助你快速开始工作，过后仍然需要学习必要的知识。
虽然是说HttpClient，这里的概念也适用于HttpComponents或者Java的HttpURLConnection或者任何语言的任何HTTP通信库。所以，即便不使用Java和HttpClient，仍然是非常有用的。
场景
假定你有一些重复的、基于web的任务，你想让其实现自动化。例如：
- 访问页面 http://a.b.c/login.html
- 输入用户名和密码，点击登录按钮
- 导航到特定的页面
- 检查那个页面上的一些数据
这一次，我们没有一个特定的例子，所以，本文档都是空对空的讲述，你必须自己来写细节的东西。
附加说明
上面的场景，对于HTTP的使用来说，a bad practice。web站点被设计用于用户交互（UI），而非应用接口（API）。应该由浏览器展示。在B/S之间的HTTP通信是一个内部的API，不该被注意。
web站点可能随时更新设计，意味着你需要随时更改你的代码以确保正确执行。除非你使用的是那些公布出来的APIs，如检查新邮件等等。
不是一个浏览器(功能上可以看作一个浏览器！)
HttpClient不是一个浏览器！它是一个HTTP通信库，它仅提供了浏览器的部分功能。最根本的不同在于，HttpClient中没有UI。浏览器需要一个rendering引擎以展示页面、解释用户输入。有一个layout引擎，计算如何展示一个HTML页面，包括CSS和图片。一个Javascript解释器运行HTML中的或外部引用的js代码。UI的事件会被传给JavaScript解释器来处理。最顶层，有一些插件的接口，诸如处理Applets、PDF、movies、Flash等等。HttpClient只能被用于编码，通过使用其APIs来发送和接收HTTP消息。HttpClient的内容是完全不可知的。它能传递消息内容，但不能以任何方式渲染或处理它们。
另一个主要区别是，对bad input或HTTP标准的容忍度。浏览器需要容忍无效的用户输入，以更佳友好。HttpClient只遵守HTTP standard specification和相关的标准。它也提供了放松某些限制的手段，--按照标准所impose的。
名词
HTTP Message
HTTP消息，由请求行、请求头、请求体（可选）组成。有两种messages：requests 和 responses。他们的区别在于第一行。
HTTP Request
被发送到服务器的HTTP Message。第一行包括：目的URL、服务器应该执行该HTTP Message的方法。
HTTP Response
由服务器发送至客户端的HTTP Message，是对request的响应。第一行包含一个状态码。HTTP定义了一组状态码，例如200代表成功，404代表未找到。其他基于HTTP的协议也可以定义额外的状态码。
Method
服务器的一个操作，客户端请求的。HTTP定义了一组操作，最常用的是GET和POST。其他基于HTTP的协议可以定义额外的methods。
Header Fields
都是name-value对，且都是text。其name都是大小写不敏感的！多个values可以被赋给同一个name。RFC 2616定义了一个宽范围的header fields以处理HTTP协议的不同的aspects。其他的specifications，如RFC 2617 和 RFC2965，定义了更多的headers。一些是通用的，另一些是request或response专用的，还有一些是专门用于entity。
Entity
HTTP Message发送的data。例如，一个response可以包含你下载的页面或图像，将其作为一个entity，或者，一个request也能包括你输入到form中的parameters。HTTP Message的entity，可以有任意的data 格式，通常在一个header field中指定其MIME type。
Session
从某个源到一个服务器的一系列requests。服务器可以持有session data，并需要识别每个incoming request所属的session。
Cookies
是让服务器跟踪session的比较好的方式。服务器会在response中提供一些数据，cookie。服务器希望客户端在接下来的request的header field里携带那些数据。不同的session有不同的cookie，所以，服务器能够辨别出一个request属于哪个session，只要看一下cookie即可。
cookies在名为Set-Cookie或Set-Cookie2的header field中。
步骤
获取Login页面
为该页面创建一个GET request，并执行。
检查response，检查cookie。
建立Session
检查是否在request中携带了cookie，检查request headers即可。
HttpClient自动解析response中的cookie，并将其存入cookie store。HttpClient使用一个可配置的cookie政策来决定server发送的cookie是否正确。默认的政策严格执行RFC 2109，但很多服务器不执行！挨个执行cookie政策，直到cookie被接受并存入cookie store中。
如果cookie没有随新request一起发送，请检查HttpClient是否使用了相同的cookie store对象！除非你显式的管理cookie store对象（不建议新手这样做），否则不会出现这样的情况。
如果cookie还是没有随新request一起发送，检查你请求的URL是否在cookie的scope之内！cookies只会被发送到域名以及cookie scope中指定的path。例如，”jakarta.apache.org”的cookie 不会被发送至”tomcat.apache.org”。但 “.apache.org” 的 cookie可以被发送至二者。”apache.org”的cookie不会被发送至”tomcat.apache.org”。后一种情况可以通过使用不同的cookie spec来解决，例如添加前导点。
如果cookie随新request一起发送了，但服务器返回了新的cookie，请检查是否在request中存在该session cookie之外的cookies。一些服务器不能探测在各自独立的header fields中发送的多个cookies。HttpClient可以将所有的cookies放入一个单独的header field。
分析Form
method
指定提供form的method。默认GET。如果是GET，会将parameters追加到URL后面。如果是POST，会将parameters放入request的entity（也叫request body）。
action
指定request发送至的URL。
enctype=
指定request的entity（entity由form生成）的MIME type。两种常见情况下，url-encoded（默认）和multipart-mime。该attribute仅用于POST，GET一直是url-encoded。
accept-charset=
指定浏览器允许用户输入的character set。
一些header fields由HttpClient控制，不能显式的设置。其他header fields用于指示浏览器拥有的能力。
Host
由HttpClient控制。通常获取自你要访问的URL。也可能设置一个不同的值，”virtual host”。
Content-Type, Content-Length, Transfer-Encoding
由HttpClient控制。其值自request entity中获取。
Connection
通常由HttpClient控制，以处理connection keep-alive。不设置，或设为close。
Content-Encoding
用于指示处理压缩过的responses的能力。不要设置这个，除非你准备实现解压缩。
重定向
针对POST request，服务器返回303或307状态码是很常见的。这些重定向意味着你的应用必须发送另一个请求以获取结果。
HttpClient可被设置成自动重定向。因为RFC2616说自动重定向应由UI负责，我们遵守这个，但也不会阻止你实现不同的行为。redirect response中的Location header field，指示了实际需要访问的URL。虽然specification要求返回一个绝对路径，但返回相对URL也是很常见的。