httpclient4 中文版帮助文档

httpclient4 中文版帮助文档，最新官方版翻译版

前言

超文本传输协议（HTTP）也许是当今互联网上使用的最重要的协议了。Web服务，有网络功能的设备和网络计算的发展，都持续扩展了HTTP协议的角色，超越了用户使用的Web浏览器范畴，同时，也增加了需要HTTP协议支持的应用程序的数量。

尽管包提供了基本通过HTTP访问资源的功能，但它没有提供全面的灵活性和其它很多应用程序需要的功能。HttpClient就是寻求弥补这项空白的组件，通过提供一个有效的，保持更新的，功能丰富的软件包来实现客户端最新的HTTP标准和建议。

为扩展而设计，同时为基本的HTTP协议提供强大的支持，HttpClient组件也许就是构建HTTP客户端应用程序，比如web浏览器，web服务端，利用或扩展HTTP协议进行分布式通信的系统的开发人员的关注点。

1. HttpClient的范围

基于HttpCore[/httpcomponents-core/]的客户端HTTP运输实现库

基于经典（阻塞）I/O

内容无关

2. 什么是HttpClient不能做的

HttpClient 不是一个浏览器。它是一个客户端的HTTP通信实现库。HttpClient的目标是发送和接收HTTP报文。HttpClient不会去缓存内容，执行 嵌入在HTML页面中的javascript代码，猜测内容类型，重新格式化请求/重定向URI，或者其它和HTTP运输无关的功能。

第一章 基础

1.1 执行请求

HttpClient 最重要的功能是执行HTTP方法。一个HTTP方法的执行包含一个或多个HTTP请求/HTTP响应交换，通常由HttpClient的内部来处理。而期望用户提供一个要执行的请求对象，而HttpClient期望传输请求到目标服务器并返回对应的响应对象，或者当执行不成功时抛出异常。

很自然地，HttpClient API的主要切入点就是定义描述上述规约的HttpClient接口。

这里有一个很简单的请求执行过程的示例：

HttpClient httpclient = new DefaultHttpClient();

HttpGet httpget = new HttpGet("localhost/");

HttpResponse response = e(httpget);

HttpEntity entity = ity();

if (entity != null) {

InputStream instream = tent();

int l;

byte[] tmp = new byte[2048];

while ((l = (tmp)) != -1) {

}

}

1.1.1 HTTP请求

所有HTTP请求有一个组合了方法名，请求URI和HTTP协议版本的请求行。

HttpClient 支持所有定义在HTTP/1.1版本中的HTTP方法：GET，HEAD，POST，PUT，DELETE，TRACE和OPTIONS。对于每个方法类 型都有一个特殊的类：HttpGet，HttpHead，HttpPost，HttpPut，HttpDelete，HttpTrace和 HttpOptions。

请求的URI是统一资源定位符，它标识了应用于哪个请求之上的资源。HTTP请求URI包含一个协议模式，主机名称，可选的端口，资源路径，可选的查询和可选的片段。

HttpGet httpget = new HttpGet(

"/search?hl=en&q=httpclient&btnG=Google+Search&aq=f&oq=");

HttpClient提供很多工具方法来简化创建和修改执行URI。

URI也可以编程来拼装：

URI uri = URI("http", "", -1, "/search",

"q=httpclient&btnG=Google+Search&aq=f&oq=", null);

HttpGet httpget = new HttpGet(uri);

n(());

输出内容为：

/search?q=httpclient&btnG=Google+Search&aq=f&oq=

查询字符串也可以从独立的参数中来生成：

List qparams = new ArrayList();

(new BasicNameValuePair("q", "httpclient"));

(new BasicNameValuePair("btnG", "Google Search"));

(new BasicNameValuePair("aq", "f"));

(new BasicNameValuePair("oq", null));

URI uri = URI("http", "", -1, "/search",

(qparams, "UTF-8"), null);

HttpGet httpget = new HttpGet(uri);

n(());

输出内容为：

/search?q=httpclient&btnG=Google+Search&aq=f&oq=

1.1.2 HTTP响应

HTTP响应是由服务器在接收和解释请求报文之后返回发送给客户端的报文。响应报文的第一行包含了协议版本，之后是数字状态码和相关联的文本段。

HttpResponse response = new BasicHttpResponse(_1_1,

_OK, "OK");

n(tocolVersion());

n(tusLine().getStatusCode());

n(tusLine().getReasonPhrase());

n(tusLine().toString());

输出内容为：

HTTP/1.1

200

OK

HTTP/1.1 200 OK

1.1.3 处理报文头部

一个HTTP报文可以包含很多描述如内容长度，内容类型等信息属性的头部信息。

HttpClient提供获取，添加，移除和枚举头部信息的方法。

HttpResponse response = new BasicHttpResponse(_1_1,

_OK, "OK");

der("Set-Cookie",

"c1=a; path=/; domain=localhost");

der("Set-Cookie",

"c2=b; path="/", c3=c; domain="localhost"");

Header h1 = stHeader("Set-Cookie");

n(h1);

Header h2 = tHeader("Set-Cookie");

n(h2);

Header[] hs = ders("Set-Cookie");

n();

输出内容为：

Set-Cookie: c1=a; path=/; domain=localhost

Set-Cookie: c2=b; path="/", c3=c; domain="localhost"

获得给定类型的所有头部信息最有效的方式是使用HeaderIterator接口。

HttpResponse response = new BasicHttpResponse(_1_1,

_OK, "OK");

der("Set-Cookie",

"c1=a; path=/; domain=localhost");

der("Set-Cookie",

"c2=b; path="/", c3=c; domain="localhost"");

HeaderIterator it = Iterator("Set-Cookie");

while (t()) {

n(());

}

输出内容为：

Set-Cookie: c1=a; path=/; domain=localhost

Set-Cookie: c2=b; path="/", c3=c; domain="localhost"

它也提供解析HTTP报文到独立头部信息元素的方法方法。

HttpResponse response = new BasicHttpResponse(_1_1,

_OK, "OK");

der("Set-Cookie",

"c1=a; path=/; domain=localhost");

der("Set-Cookie",

"c2=b; path="/", c3=c; domain="localhost"");

HeaderElementIterator it = new BasicHeaderElementIterator(

Iterator("Set-Cookie"));

while (t()) {

HeaderElement elem = ement();

n(e() + " = " + ue());

NameValuePair[] params = ameters();

for (int i = 0; i < ; i++) {

n(" " + params[i]);

}

}

输出内容为：

c1 = a

path=/

domain=localhost

c2 = b

path=/

c3 = c

domain=localhost

1.1.4 HTTP实体

HTTP 报文可以携带和请求或响应相关的内容实体。实体可以在一些请求和响应中找到，因为它们也是可选的。使用了实体的请求被称为封闭实体请求。HTTP规范定义 了两种封闭实体的方法：POST和PUT。响应通常期望包含一个内容实体。这个规则也有特例，比如HEAD方法的响应和204 No Content，304 Not Modified和205 Reset Content响应。

HttpClient根据其内容出自何处区分三种类型的实体：

streamed流式：内容从流中获得，或者在运行中产生。特别是这种分类包含从HTTP响应中获取的实体。流式实体是不可重复生成的。

self-contained自我包含式：内容在内存中或通过独立的连接或其它实体中获得。自我包含式的实体是可以重复生成的。这种类型的实体会经常用于封闭HTTP请求的实体。

wrapping包装式：内容从另外一个实体中获得。

当从一个HTTP响应中获取流式内容时，这个区别对于连接管理很重要。对于由应用程序创建而且只使用HttpClient发送的请求实体，流式和自我包含式的不同就不那么重要了。这种情况下，建议考虑如流式这种不能重复的实体，和可以重复的自我包含式实体。

1.1.4.1 重复实体

实体可以重复，意味着它的内容可以被多次读取。这就仅仅是自我包含式的实体了（像ByteArrayEntity或StringEntity）。

1.1.4.2 使用HTTP实体

因为一个实体既可以代表二进制内容又可以代表字符内容，它也支持字符编码（支持后者也就是字符内容）。

实体是当使用封闭内容执行请求，或当请求已经成功执行，或当响应体结果发功到客户端时

创建的。

要 从实体中读取内容，可以通过HttpEntity#getContent()方法从输入流中获取，这会返回一个tream对 象，或者提供一个输出流到HttpEntity#writeTo(OutputStream)方法中，这会一次返回所有写入到给定流中的内容。

当 实体通过一个收到的报文获取时，HttpEntity#getContentType()方法和

HttpEntity#getContentLength()方法可以用来读取通用的元数据，如Content-Type和Content-Length 头部信息（如果它们是可用的）。因为头部信息Content-Type可以包含对文本MIME类型的字符编码，比如text/plain或text /html，HttpEntity#getContentEncoding()方法用来读取这个信息。如果头部信息不可用，那么就返回长度-1，而对于内 容类型返回NULL。如果头部信息Content-Type是可用的，那么就会返回一个Header对象。

当为一个传出报文创建实体时，这个元数据不得不通过实体创建器来提供。

StringEntity myEntity = new StringEntity("important message",

"UTF-8");

n(tentType());

n(tentLength());

n(tentCharSet(myEntity));

n(ng(myEntity));

n(Array(myEntity).length);

输出内容为

Content-Type: text/plain; charset=UTF-8

17

UTF-8

important message

17

1.1.5 确保低级别资源释放

当 完成一个响应实体，那么保证所有实体内容已经被完全消耗是很重要的，所以连接可以安全的放回到连接池中，而且可以通过连接管理器对后续的请求重用连接。处 理这个操作的最方便的方法是调用HttpEntity#consumeContent()方法来消耗流中的任意可用内容。HttpClient探测到内容 流尾部已经到达后，会立即会自动释放低层连接，并放回到连接管理器。HttpEntity#consumeContent()方法调用多次也是安全的。

也可能会有特殊情况，当整个响应内容的一小部分需要获取，消耗剩余内容而损失性能，还有重用连接的代价太高，则可以仅仅通过调用HttpUriRequest#abort()方法来中止请求。

HttpGet httpget = new HttpGet("localhost/");

HttpResponse response = e(httpget);

HttpEntity entity = ity();

if (entity != null) {

InputStream instream = tent();

int byteOne = ();

int byteTwo = ();

// Do not need the rest

();

}

连接不会被重用，但是由它持有的所有级别的资源将会被正确释放。

1.1.6 消耗实体内容

推 荐消耗实体内容的方式是使用它的HttpEntity#getContent()或HttpEntity#writeTo(OutputStream)方 法。HttpClient也自带EntityUtils类，这会暴露出一些静态方法，这些方法可以更加容易地从实体中读取内容或信息。代替直接读取

tream，也可以使用这个类中的方法以字符串/字节数组的形式获取整个内容体。然而，EntityUtils的使用是强烈 不鼓励的，除非响应实体源自可靠的HTTP服务器和已知的长度限制。

HttpGet httpget = new HttpGet("localhost/");

HttpResponse response = e(httpget);

HttpEntity entity = ity();

if (entity != null) {

long len = tentLength();

if (len != -1 && len < 2048) {

n(ng(entity));

} else {

// Stream content out

}

}

在一些情况下可能会不止一次的读取实体。此时实体内容必须以某种方式在内存或磁盘上被缓冲起来。最简单的方法是通过使用BufferedHttpEntity类来包装源实体完成。这会引起源实体内容被读取到内存的缓冲区中。在其它所有方式中，实体包装器将会得到源实体。

HttpGet httpget = new HttpGet("localhost/");

HttpResponse response = e(httpget);

HttpEntity entity = ity();

if (entity != null) {

entity = new BufferedHttpEntity(entity);

}

1.1.7 生成实体内容

HttpClient 提供一些类，它们可以用于生成通过HTTP连接获得内容的有效输出流。为了封闭实体从HTTP请求中获得的输出内容，那些类的实例可以和封闭如POST和 PUT请求的实体相关联。HttpClient为很多公用的数据容器，比如字符串，字节数组，输入流和文件提供了一些 类：StringEntity，ByteArrayEntity，InputStreamEntity和FileEntity。

File file = new File("");

FileEntity entity = new FileEntity(file, "text/plain; charset="UTF-8"");

HttpPost httppost = new HttpPost("localhost/");

ity(entity);

请 注意InputStreamEntity是不可重复的，因为它仅仅能从低层数据流中读取一次内容。通常来说，我们推荐实现一个定制的HttpEntity 类，这是自我包含式的，用来代替使用通用的InputStreamEntity。FileEntity也是一个很好的起点。

1.1.7.1 动态内容实体

通 常来说，HTTP实体需要基于特定的执行上下文来动态地生成。通过使用EntityTemplate

实体类和ContentProducer接 口，HttpClient提供了动态实体的支持。内容生成器是按照需求生成它们内容的对象，将它们写入到一个输出流中。它们是每次被请求时来生成内容。所

以用EntityTemplate创建的实体通常是自我包含而且可以重复的。

ContentProducer cp = new ContentProducer() {

public void writeTo(OutputStream outstream) throws IOException {

Writer writer = new OutputStreamWriter(outstream, "UTF-8");

("");

(" ");

(" important stuff");

(" ");

("");

();

}

};

HttpEntity entity = new EntityTemplate(cp);

HttpPost httppost = new HttpPost("localhost/");

ity(entity);

1.1.7.2 HTML表单

许多应用程序需要频繁模拟提交一个HTML表单的过程，比如，为了来记录一个Web应用程序或提交输出数据。HttpClient提供了特殊的实体类UrlEncodedFormEntity来这个满足过程。

List formparams = new ArrayList();

(new BasicNameValuePair("param1", "value1"));

(new BasicNameValuePair("param2", "value2"));

UrlEncodedFormEntity entity = new UrlEncodedFormEntity(formparams, "UTF-8");

HttpPost httppost = new HttpPost("localhost/");

ity(entity);

UrlEncodedFormEntity实例将会使用URL编码来编码参数，生成如下的内容：

param1=value1¶m2=value2

1.1.7.3 内容分块

通 常，我们推荐让HttpClient选择基于被传递的HTTP报文属性的最适合的编码转换。这是可能的，但是，设置 HttpEntity#setChunked()方法为true是通知HttpClient分块编码的首选。请注意HttpClient将会使用标识作为 提示。当使用的HTTP协议版本，如HTTP/1.0版本，不支持分块编码时，这个值会被忽略。

StringEntity entity = new StringEntity("important message",

"text/plain; charset="UTF-8"");

nked(true);

HttpPost httppost = new HttpPost("localhost/");

ity(entity);

1.1.8 响应控制器

控制响应的最简便和最方便的方式是使用ResponseHandler接口。这个放完完全减轻了用

户关于连接管理的担心。当使用ResponseHandler时，HttpClient将会自动关注并保证释放连接到连接管理器中去，而不管请求执行是否成功或引发了异常。

HttpClient httpclient = new DefaultHttpClient();

HttpGet httpget = new HttpGet("localhost/");

ResponseHandler handler = new ResponseHandler() {

public byte[] handleResponse(

HttpResponse response) throws ClientProtocolException, IOException {

HttpEntity entity = ity();

if (entity != null) {

return Array(entity);

} else {

return null;

}

}

};

byte[] response = e(httpget, handler);

1.2 HTTP执行的环境

最 初，HTTP是被设计成无状态的，面向请求-响应的协议。然而，真实的应用程序经常需要通过一些逻辑相关的请求-响应交换来持久状态信息。为了开启应用程 序来维持一个过程状态，HttpClient允许HTTP请求在一个特定的执行环境中来执行，简称为HTTP上下文。如果相同的环境在连续请求之间重用， 那么多种逻辑相关的请求可以参与到一个逻辑会话中。HTTP上下文功能和很相似。 它仅仅是任意命名参数值的集合。应用程序可以在请求之前或在检查上下文执行完成之后来填充上下文属性。

在HTTP请求执行的这一过程中，HttpClient添加了下列属性到执行上下文中：

'tion'：HttpConnection实例代表了连接到目标服务器的真实连接。

'_host'：HttpHost实例代表了连接目标。

'_host'：如果使用了，HttpHost实例代表了代理连接。

't'：HttpRequest实例代表了真实的HTTP请求。

'se'：HttpResponse实例代表了真实的HTTP响应。

't_sent'：n对象代表了暗示真实请求是否被完全传送到目标连接的标识。

比如，为了决定最终的重定向目标，在请求执行之后，可以检查_host属性的值：

DefaultHttpClient httpclient = new DefaultHttpClient();

HttpContext localContext = new BasicHttpContext();

HttpGet httpget = new HttpGet("/");

HttpResponse response = e(httpget, localContext);

HttpHost target = (HttpHost) ribute(

_TARGET_HOST);

n("Final target: " + target);

HttpEntity entity = ity();

if (entity != null) {

eContent();

}

输出内容为：

Final target:

1.3 异常处理

HttpClient 能够抛出两种类型的异常：在I/O失败时，如套接字连接超时或被重置的ption异常，还有标志HTTP请求失败的信号，如 违反HTTP协议的HttpException异常。通常I/O错误被认为是非致命的和可以恢复的，而HTTP协议错误则被认为是致命的而且是不能自动恢 复的。

1.3.1 HTTP运输安全

要 理解HTTP协议并不是对所有类型的应用程序都适合的，这一点很重要。HTTP是一个简单的面向请求/响应的协议，最初被设计用来支持取回静态或动态生成 的内容。它从未向支持事务性操作方向发展。比如，如果成功收到和处理请求，HTTP服务器将会考虑它的其中一部分是否完成，生成一个响应并发送一个状态码 到客户端。如果客户端因为读取超时，请求取消或系统崩溃导致接收响应实体失败时，服务器不会试图回滚事务。如果客户端决定重新这个请求，那么服务器将不可 避免地不止一次执行这个相同的事务。在一些情况下，这会导致应用数据损坏或者不一致的应用程序状态。

尽管HTTP从来都没有被设计来支持事务性处理，但它也能被用作于一个传输协议对关键的任务应用提供被满足的确定状态。要保证HTTP传输层的安全，系统必须保证HTTP方法在应用层的幂等性。

1.3.2 幂等的方法

HTTP/1.1 明确地定义了幂等的方法，描述如下

[方法也可以有“幂等”属性在那些（除了错误或过期问题）N的副作用>0的相同请求和独立的请求是相同的]

换句话说，应用程序应该保证准备着来处理多个相同方法执行的实现。这是可以达到的，比如，通过提供一个独立的事务ID和其它避免执行相同逻辑操作的方法。

请注意这个问题对于HttpClient是不具体的。基于应用的浏览器特别受和非幂等的HTTP方法相关的相同问题的限制。

HttpClient假设没有实体包含方法，比如GET和HEAD是幂等的，而实体包含方法，比如POST和PUT则不是。

1.3.3 异常自动恢复

默认情况下，HttpClient会试图自动从I/O异常中恢复。默认的自动恢复机制是受很少一部分已知的异常是安全的这个限制。

HttpClient不会从任意逻辑或HTTP协议错误（那些是从HttpException类中派生出的）中恢复的。

HttpClient将会自动重新执行那么假设是幂等的方法。

HttpClient将会自动重新执行那些由于运输异常失败，而HTTP请求仍然被传送到目标服务器（也就是请求没有完全被送到服务器）失败的方法。

HttpClient 将会自动重新执行那些已经完全被送到服务器，但是服务器使用HTTP状态码（服务器仅仅丢掉连接而不会发回任何东西）响应时失败的方法。在这种情况下，假 设请求没有被服务器处理，而应用程序的状态也没有改变。如果这个假设可能对于你应用程序的目标Web服务器来说不正确，那么就强烈建议提供一个自定义的异 常处理器。

1.3.4 请求重试处理

为了开启自定义异常恢复机制，应该提供一个HttpRequestRetryHandler接口的实现。

DefaultHttpClient httpclient = new DefaultHttpClient();

HttpRequestRetryHandler myRetryHandler = new HttpRequestRetryHandler() {

public boolean retryRequest(IOException exception,

int executionCount,HttpContext context) {

if (executionCount >= 5) {

// 如果超过最大重试次数，那么就不要继续了

return false;

}

if (exception instanceof NoHttpResponseException) {

// 如果服务器丢掉了连接，那么就重试

return true;

}

if (exception instanceof SSLHandshakeException) {

// 不要重试SSL握手异常

return false;

}

HttpRequest request = (HttpRequest) ribute(

_REQUEST);

boolean idempotent = !(request instanceof HttpEntityEnclosingRequest);

if (idempotent) {

// 如果请求被认为是幂等的，那么就重试

return true;

}

return false;

}

};

pRequestRetryHandler(myRetryHandler);

1.4 中止请求

在 一些情况下，由于目标服务器的高负载或客户端有很多活动的请求，那么HTTP请求执行会在预期的时间框内而失败。这时，就可能不得不过早地中止请求，解除 封锁在I/O执行中的线程封锁。被HttpClient执行的HTTP请求可以在执行的任意阶段通过调用HttpUriRequest#abort()方 法而中止。这个方法是线程安全的，而且可以从任意线程中调用。当一个HTTP请求被中止时，它的执行线程就封锁在I/O操作中了，而且保证通过抛出

InterruptedIOException异常来解锁。

1.5 HTTP协议拦截器

HTTP 协议拦截器是一个实现了特定HTPP协议方面的惯例。通常协议拦截器希望作用于一个特定头部信息上，或者一族收到报文的相关头部信息，或使用一个特定的头 部或一族相关的头部信息填充发出的报文。协议拦截器也可以操纵包含在报文中的内容实体，透明的内容压缩/解压就是一个很好的示例。通常情况下这是由包装器 实体类使用了“装饰者”模式来

装饰原始的实体完成的。一些协议拦截器可以从一个逻辑单元中来结合。

协议拦截器也可以通过共享信息来共同合作-比如处理状态-通过HTTP执行上下文。协议拦截器可以使用HTTP内容来为一个或多个连续的请求存储一个处理状态。

通常拦截器执行的顺序不应该和它们基于的特定执行上下文状态有关。如果协议拦截器有相互依存关系，那么它们必须按特定顺序来执行，正如它们希望执行的顺序一样，它们应该在相同的序列中被加到协议处理器。

协议拦截器必须实现为线程安全的。和Servlet相似，协议拦截器不应该使用实例变量，除非访问的那些变量是同步的。

这个示例给出了本地内容在连续的请求中怎么被用于持久一个处理状态的：

DefaultHttpClient httpclient = new DefaultHttpClient();

HttpContext localContext = new BasicHttpContext();

AtomicInteger count = new AtomicInteger(1);

ribute("count", count);

uestInterceptor(new HttpRequestInterceptor() {

public void process(final HttpRequest request,

final HttpContext context) throws HttpException, IOException {

AtomicInteger count = (AtomicInteger) ribute("count");

der("Count", ng(Increment()));

}

});

HttpGet httpget = new HttpGet("localhost/");

for (int i = 0; i < 10; i++) {

HttpResponse response = e(httpget, localContext);

HttpEntity entity = ity();

if (entity != null) {

eContent();

}

}

1.6 HTTP参数

HttpParams 接口代表了定义组件运行时行为的一个不变的值的集合。很多情况下，HttpParams和HttpContext相似。二者之间的主要区别是它们在运行时 使用的不同。这两个接口表示了对象的集合，它们被视作为访问对象值的键的Map，但是服务于不同的目的：

HttpParams旨在包含简单对象：整型，浮点型，字符串，集合，还有运行时不变的对象。

HttpParams希望被用在“一次写入-多处准备”模式下。HttpContext旨在包含很可能在HTTP报文处理这一过程中发生改变的复杂对象

HttpParams的目标是定义其它组件的行为。通常每一个复杂的组件都有它自己的HttpParams对象。HttpContext的目标是来表示一个HTTP处理的执行状态。通常相同的执行上下文在很多合作的对象中共享。

1.6.1 参数层次

在 HTTP请求执行过程中，HttpRequest对象的HttpParams是和用于执行请求的HttpClient实例的HttpParams联系在一 起的。这使得设置在HTTP请求级别的参数优先于设置在HTTP客户端级别的HttpParams。推荐的做法是设置普通参数对所有的在HTTP客户端级 别

的HTTP请求共享，而且可以选择性重写具体在HTTP请求级别的参数。

DefaultHttpClient httpclient = new DefaultHttpClient();

ams().setParameter(OL_VERSION,_1_0);

ams().setParameter(_CONTENT_CHARSET,"UTF-8");

HttpGet httpget = new HttpGet("/");

ams().setParameter(OL_VERSION,_1_1);

ams().setParameter(_EXPECT_CONTINUE,);

uestInterceptor(new HttpRequestInterceptor() {

public void process(final HttpRequest request,

final HttpContext context) throws HttpException, IOException {

n(ams().getParameter(

OL_VERSION));

n(ams().getParameter(

_CONTENT_CHARSET));

n(ams().getParameter(

_EXPECT_CONTINUE));

n(ams().getParameter(

_TRANSFER_ENCODING));

}

});

输出内容为：

HTTP/1.1

UTF-8

false

null

1.6.2 HTTP参数bean

HttpParams 接口允许在处理组件的配置上很大的灵活性。很重要的是，新的参数可以被引入而不会影响老版本的二进制兼容性。然而，和常规的Java bean相比，HttpParams也有一个缺点：HttpParams不能使用DI框架来组合。为了缓解这个限制，HttpClient包含了一些 bean类，它们可以用来按顺序使用标准的Java eban惯例初始化HttpParams对象。

HttpParams params = new BasicHttpParams();

HttpProtocolParamBean paramsBean = new HttpProtocolParamBean(params);

sion(_1_1);

tentCharset("UTF-8");

ExpectContinue(true);

n(ameter(

OL_VERSION));

n(ameter(

_CONTENT_CHARSET));

n(ameter(

_EXPECT_CONTINUE));

n(ameter(

_AGENT));

输出内容为：

HTTP/1.1

UTF-8

false

null

1.7 HTTP请求执行参数

这些参数会影响到请求执行的过程：

'n'：如果没有在请求对象中设置明确的版本信息，它就定义了使用的HTTP协议版本。这个参数期望得到一个ProtocolVersion类型的值。如果这个参数没有被设置，那么就使用HTTP/1.1。

't-charset'：定义了编码HTTP协议元素的字符集。这个参数期望得到一个类型的值。如果这个参数没有被设置，那么就使用US-ASCII。

't-charset'：定义了为每个内容主体编码的默认字符集。这个参数期望得到一个类型的值。如果这个参数没有被设置，那么就使用ISO-8859-1。

'ent'：定义了头部信息User-Agent的内容。这个参数期望得到一个类型的值。如果这个参数没有被设置，那么HttpClient将会为它自动生成一个值。

'-transfer-encoding'：定义了响应头部信息中是否含有一个非法的Transfer-Encoding，都要拒绝掉。

'- continue'：为包含方法的实体激活Expect: 100-Continue握手。Expect:

100-Continue握手的目的是允许客户端使用请求体发送一个请求信息来决定源服务器是否希望在客户端发送请求体之前得到这个请求（基于请求头部信 息）。Expect: 100-Continue握手的使用可以对需要目标服务器认证的包含请求的实体（比如POST和PUT）导致明显的性能改善。Expect: 100-Continue握手应该谨慎使用，因为它和HTTP服务器，不支持HTTP/1.1协议的代理使用会引起问题。这个参数期望得到一个 n类型的值。如果这个参数没有被设置，那么HttpClient将会试图使用握手。

'- for-continue'：定义了客户端应该等待100-Continue响应最大的毫秒级时间间隔。这个参数期望得到一个 r类型的值。如果这个参数没有被设置，那么HttpClient将会在恢复请求体传输之前为确认等待3秒。

第二章 连接管理

HttpClient有一个对连接初始化和终止，还有在活动连接上I/O操作的完整控制。而连接操作的很多方面可以使用一些参数来控制。

2.1 连接参数

这些参数可以影响连接操作：

't'： 定义了套接字的毫秒级超时时间（SO_TIMEOUT），这就是等待数据，换句话说，在两个连续的数据包之间最大的闲置时间。如果超时时间是0就解释为是 一个无限大的超时时间。这个参数期望得到一个r类型的值。如果这个参数没有被设置，那么读取操作就不会超时（无限大的超 时时间）。

'y'： 决定了是否使用Nagle算法。Nagle算法视图通过最小化发送的分组数量来节省带宽。当应用程序希望降低网络延迟并提高性能时，它们可以关闭 Nagle算法（也就是开启TCP_NODELAY）。数据将会更早发送，增加了带宽消耗的成文。这个参数期望得到一个 n类型的值。如果这个参数没有被设置，那么TCP_NODELAY就会开启（无延迟）。

'- size'：决定了内部套接字缓冲使用的大小，来缓冲数据同时接收/传输HTTP报文。这个参数期望得到一个r类型的 值。如果这个参数没有被设置，那么HttpClient将会分配8192字节的套接字缓存。

''： 使用指定的秒数拖延时间来设置SO_LINGER。最大的连接超时值是平台指定的。值0暗示了这个选项是关闭的。值-1暗示了使用了JRE默认的。这个设 置仅仅影响套接字关闭操作。如果这个参数没有被设置，那么就假设值为-1（JRE默认）。

't'： 决定了直到连接建立时的毫秒级超时时间。超时时间的值为0解释为一个无限大的时间。这个参数期望得到一个r类型的值。如 果这个参数没有被设置，连接操作将不会超时（无限大的超时时间）。

'heck'： 决定了是否使用旧的连接检查。当在一个连接之上执行一个请求而服务器端的连接已经关闭时，关闭旧的连接检查可能导致在获得一个I/O错误风险时显著的性能 提升（对于每一个请求，检查时间可以达到30毫秒）。这个参数期望得到一个n类型的值。出于性能的关键操作，检查应该被 关闭。如果这个参数没有被设置，那么旧的连接将会在每个请求执行之前执行。

'- line-length'：决定了最大请求行长度的限制。如果设置为一个正数，任何HTTP请求行超过这个限制将会引发 ption异常。负数或零将会关闭这个检查。这个参数期望得到一个r类型的值。如果这个参 数没有被设置，那么就不强制进行限制了。

'- header-count'：决定了允许的最大HTTP头部信息数量。如果设置为一个正数，从数据流中获得的HTTP头部信息数量超过这个限制就会引发

ption异常。负数或零将会关闭这个检查。这个参数期望得到一个r类型的值。如果这个参 数没有被设置，那么就不

强制进行限制了。

'- status-line-garbage'：决定了在期望得到HTTP响应状态行之前可忽略请求行的最大数量。使用HTTP/1.1持久性连接，这个问题 产生的破碎的脚本将会返回一个错误的Content-Length（有比指定的字节更多的发送）。不幸的是，在某些情况下，这个不能在错误响应后来侦测， 只能在下一次之前。所以HttpClient必须以这种方式跳过那些多余的行。这个参数期望得到一个r类型的值。0是不 允许在状态行之前的所有垃圾/空行。使用r#MAX_VALUE来设置不限制的数字。如果这个参数没有被设置那就假设是 不限制的。

2.2 持久连接

从一个主机向另外一个建立连接的过程是相当复杂的，而且包含了两个终端之间的很多包的交换，它是相当费时的。连接握手的开销是很重要的，特别是对小量的HTTP报文。如果打开的连接可以被重用来执行多次请求，那么就可以达到很高的数据吞吐量。

HTTP/1.1 强调HTTP连接默认情况可以被重用于多次请求。HTTP/1.0兼容的终端也可以使用相似的机制来明确地交流它们的偏好来保证连接处于活动状态，也使用 它来处理多个请求。HTTP代理也可以保持空闲连接处于一段时间的活动状态，防止对相同目标主机的一个连接也许对随后的请求需要。保持连接活动的能力通常 被称作持久性连接。HttpClient完

全支持持久性连接。

2.3 HTTP连接路由

HttpClient能够直接或通过路由建立连接到目标主机，这会涉及多个中间连接，也被称为跳。HttpClient区分路由和普通连接，通道和分层。通道连接到目标主机的多个中间代理的使用也称作是代理链。

普通路由由连接到目标或仅第一次的代理来创建。通道路由通过代理链到目标连接到第一通道来建立。没有代理的路由不是通道的，分层路由通过已存在连接的分层协议来建立。协议仅仅可以在到目标的通道上或在没有代理的直接连接上分层。

2.3.1 路由计算

RouteInfo 接口代表关于最终涉及一个或多个中间步骤或跳的目标主机路由的信息。HttpRoute是RouteInfo的具体实现，这是不能改变的（是不变的）。 HttpTracker是可变的RouteInfo实现，由HttpClient在内部使用来跟踪到最大路由目标的剩余跳数。HttpTracker可以 在成功执行向路由目标的下一跳之后更新。HttpRouteDirector是一个帮助类，可以用来计算路由中的下一跳。这个类由HttpClient在 内部使用。

HttpRoutePlanner 是一个代表计算到基于执行上下文到给定目标完整路由策略的接口。HttpClient附带两个默认的HttpRoutePlanner实现。 ProxySelectorRoutePlanner是基于elector的。默认情况下，它会从系统属性中或从运行应用 程序的浏览器中选取JVM的代理设置。DefaultHttpRoutePlanner实现既不使用任何Java系统属性，也不使用系统或浏览器的代理设 置。它只基于HTTP如下面描述的参数计算路由。

2.3.2 安全HTTP连接

如果信息在两个不能由非认证的第三方进行读取或修改的终端之间传输，HTTP连接可以被认为是安全的。SSL/TLS协议是用来保证HTTP传输安全使用最广泛的技术。而其它加密技术也可以被使用。通常来说，HTTP传输是在SSL/TLS加密连接之上分层的。

2.4 HTTP路由参数

这些参数可以影响路由计算：

't-proxy'：定义可以被不使用JRE设置的默认路由规划者使用的代理主机。这个参数期望得到一个HttpHost类型的值。如果这个参数没有被设置，那么就会尝试直接连接到目标。

'- address'：定义一个本地地址由所有默认路由规划者来使用。有多个网络接口的机器中，这个参数可以被用于从连接源中选择网络接口。这个参数期望得到 一个dress类型的值。如果这个参数没有被设置，将会自动使用本地地址。

'- route'：定义一个由所有默认路由规划者使用的强制路由。代替了计算路由，给定的强制路由将会被返回，尽管它指向一个完全不同的目标主机。这个参数期 望得到一个HttpRoute类型的值。如果这个参数没有被设置，那么就使用默认的规则建立连接到目标服务器。

2.5 套接字工厂

LayeredSocketFactory 是SocketFactory接口的扩展。分层的套接字工厂可HTTP连接内部使用对象来处理数据在线路上的传输。它们依 赖SocketFactory接口来创建，初始化和连接套接字。这会使得HttpClient的用户可以提供在运行时指定套接字初始化

代码的应用程序。 PlainSocketFactory是创建和初始化普通的（不加密的）套接字的默认工厂。

创建套接字的过程和连接到主机的过程是不成对的，所以套接字在连接操作封锁时可以被关闭。

PlainSocketFactory sf = ketFactory();

Socket socket = Socket();

HttpParams params = new BasicHttpParams();

ameter(TION_TIMEOUT, 1000L);

tSocket(socket, "locahost", 8080, null, -1, params);

2.5.1 安全套接字分层

LayeredSocketFactory 是SocketFactory接口的扩展。分层的套接字工厂可以创建在已经存在的普通套接字之上的分层套接字。套接字分层主要通过代理来创建安全的套接 字。HttpClient附带实现了SSL/TLS分层的SSLSocketFactory。请注意HttpClient不使用任何自定义加密功能。它完 全依赖于标准的Java密码学（JCE）和安全套接字（JSEE）扩展。

2.5.2 SSL/TLS的定制

HttpClient使用SSLSocketFactory来创建SSL连接。SSLSocketFactory允许高度定制。它可以使用text的实例作为参数，并使用它来创建定制SSL连接。

TrustManager easyTrustManager = new X509TrustManager() {

@Override

public void checkClientTrusted(X509Certificate[] chain,

String authType) throws CertificateException {

// 哦，这很简单！

}

@Override

public void checkServerTrusted(X509Certificate[] chain,

String authType) throws CertificateException {

//哦，这很简单！

}

@Override

public X509Certificate[] getAcceptedIssuers() {

return null;

}

};

SSLContext sslcontext = tance("TLS");

(null, new TrustManager[] { easyTrustManager }, null);

SSLSocketFactory sf = new SSLSocketFactory(sslcontext);

SSLSocket socket = (SSLSocket) Socket();

bledCipherSuites(new String[] { "SSL_RSA_WITH_RC4_128_MD5" });

HttpParams params = new BasicHttpParams();

ameter(TION_TIMEOUT, 1000L);

tSocket(socket, "locahost", 443, null, -1, params);

SSLSocketFactory的定制暗示出一定程度SSL/TLS协议概念的熟悉，这个详细的解释超出

了本文档的范围。请参考Java的安全套接字扩展[/j2se/1.5.0/docs/guide/

security/jsse/]，这是text和相关工具的详细描述。

2.5.3 主机名验证

除 了信任验证和客户端认证在SSL/TLS协议级上进行，一旦连接建立之后，HttpClient能可选地验证目标主机名匹配存储在服务器的X.509认证 中的名字。这个认证可以提供额外的服务器信任材料的真实保证。X509主机名验证接口代表了主机名验证的策略。HttpClient附带了3个X509主 机名验证器。很重要的一点是：主机名验证不应该混淆SSL信任验证。

StrictHostnameVerifier： 严格的主机名验证在Sun Java 1.4，Sun Java 5和Sun Java 6中是相同的。而且也非常接近IE6。这个实现似乎是兼容RFC 2818处理通配符的。主机名必须匹配第一个CN或任意的subject-alt。在CN和其它任意的subject-alt中可能会出现通配符。

BrowserCompatHostnameVerifier： 主机名验证器和Curl和Firefox的工作方式是相同的。主机名必须匹配第一个CN或任意的subject-alt。在CN和其它任意的 subject-alt中可能会出现通配符。BrowserCompatHostnameVerifier和 StrictHostnameVerifier的唯一不同是使用BrowserCompatHostnameVerifier匹配所有子域的通配符（比 如”*.”），包括””。

AllowAllHostnameVerifier：这个主机名验证器基本上是关闭主机名验证的。这个实现是一个空操作，而且不会抛出eption异常。

每一个默认的HttpClient使用BrowserCompatHostnameVerifier的实现。如果需要的话，它可以指定不同的主机名验证器实现。

SSLSocketFactory sf = new SSLSocketFactory(tance("TLS"));

tnameVerifier(_HOSTNAME_VERIFIER);

2.6 协议模式

Scheme 类代表了一个协议模式，比如“http”或“https”同时包含一些协议属性，比如默认端口，用来为给定协议创建实例的 套接字工厂。SchemeRegistry类用来维持一组Scheme，当去通过请求URI建立连接时，HttpClient可以从中选择：

Scheme http = new Scheme("http", ketFactory(), 80);

SSLSocketFactory sf = new SSLSocketFactory(tance("TLS"));

tnameVerifier(_HOSTNAME_VERIFIER);

Scheme https = new Scheme("https", sf, 443);

SchemeRegistry sr = new SchemeRegistry();

er(http);

er(https);

2.7 HttpClient代理配置

尽管HttpClient了解复杂的路由模式和代理链，它仅支持简单直接的或开箱的跳式代理连接。

告诉HttpClient通过代理去连接到目标主机的最简单方式是通过设置默认的代理参数：

DefaultHttpClient httpclient = new DefaultHttpClient();

HttpHost proxy = new HttpHost("someproxy", 8080);

ams().setParameter(T_PROXY, proxy);

也可以构建HttpClient使用标准的JRE代理选择器来获得代理信息：

DefaultHttpClient httpclient = new DefaultHttpClient();

ProxySelectorRoutePlanner routePlanner = new ProxySelectorRoutePlanner(

nectionManager().getSchemeRegistry(),

ault());

tePlanner(routePlanner);

另外一种选择，可以提供一个定制的RoutePlanner实现来获得HTTP路由计算处理上的复杂的控制：

DefaultHttpClient httpclient = new DefaultHttpClient();

tePlanner(new HttpRoutePlanner() {

public HttpRoute determineRoute(HttpHost target,

HttpRequest request,

HttpContext context) throws HttpException {

return new HttpRoute(target, null, new HttpHost("someproxy", 8080),

"https".equalsIgnoreCase(emeName()));

}

});

2.8 HTTP连接管理器

2.8.1 连接操作器

连 接操作是客户端的低层套接字或可以通过外部实体，通常称为连接操作的被操作的状态的连接。OperatedClientConnection接口扩展了 HttpClientConnection接口而且定义了额外的控制连接套接字的方法。ClientConnectionOperator接口代表了创建 实例和更新那些对象低层套接字的策略。实现类最有可能利用SocketFactory来创建实例。

ClientConnectionOperator接口可以让HttpClient的用户提供一个连接操作的定制策略和提供可选实现 OperatedClientConnection接口的能力。

2.8.2 管理连接和连接管理器

HTTP 连接是复杂的，有状态的，线程不安全的对象需要正确的管理以便正确地执行功能。HTTP连接在同一时间仅仅只能由一个执行线程来使用。 HttpClient采用一个特殊实体来管理访问HTTP连接，这被称为HTTP连接管理器，代表了ClientConnectionManager接 口。一个HTTP连接管理器的目的是作为工厂服务于新的HTTP连接，管理持久连接和同步访问持久连接来确保同一时间仅有一个线程可以访问一个连接。

内 部的HTTP连接管理器和OperatedClientConnection实例一起工作，但是它们为服务消耗器 ManagedClientConnection提供实例。ManagedClientConnection扮演连接之上管理状态控制所有I/O操作的 OperatedClientConnection实例的包装器。它也抽象套接字操作，提供打开和更新去创建路由套接字便利的方法。 ManagedClientConnection实例了解产生它们到连接管理器的链接，而且基于这个事实，当不再被使用时，它们必须返回到管理器。

ManagedClientConnection类也实现了ConnectionReleaseTrigger接口，可以被用来触发释放连接返回给管理 器。一旦释放连接操作被触发了，被包装的连接从ManagedClientConnection包装器中脱 离，OperatedClientConnection实例被返回给管理器。尽管服务消耗器仍然持有ManagedClientConnection实例 的引用，它也不再去执行任何I/O操作或有意无意地改变的OperatedClientConnection状态。

这里有一个从连接管理器中获取连接的示例：

HttpParams params = new BasicHttpParams();

Scheme http = new Scheme("http", ketFactory(), 80);

SchemeRegistry sr = new SchemeRegistry();

er(http);

ClientConnectionManager connMrg = new SingleClientConnManager(params, sr);

// 请求新连接。这可能是一个很长的过程。

ClientConnectionRequest connRequest = tConnection(

new HttpRoute(new HttpHost("localhost", 80)), null);

// 等待连接10秒

ManagedClientConnection conn = nection(10, S);

try {

// 用连接在做有用的事情。当完成时释放连接。

eConnection();

} catch (IOException ex) {

// 在I/O error之上终止连接。

onnection();

throw ex;

}

如果需要，连接请求可以通过调用来ClientConnectionRequest#abortRequest()方法过早地中断。这会解锁在ClientConnectionRequest#getConnection()方法中被阻止的线程。

一旦响应内容被完全消耗后，BasicManagedEntity包装器类可以用来保证自动释放低层的连接。HttpClient内部使用这个机制来实现透明地对所有从HttpClient#execute()方法中获得响应释放连接：

ClientConnectionRequest connRequest = tConnection(

new HttpRoute(new HttpHost("localhost", 80)), null);

ManagedClientConnection conn = nection(10, S);

try {

BasicHttpRequest request = new BasicHttpRequest("GET", "/");

questHeader(request);

HttpResponse response = eResponseHeader();

eResponseEntity(response);

HttpEntity entity = ity();

if (entity != null) {

BasicManagedEntity managedEntity = new BasicManagedEntity(entity, conn, true);

// 替换实体

ity(managedEntity);

}

// 使用响应对象做有用的事情。当响应内容被消耗后这个连接将会自动释放。

} catch (IOException ex) {

//在I/O error之上终止连接。

onnection();

throw ex;

}

2.8.3 简单连接管理器

SingleClientConnManager 是一个简单的连接管理器，在同一时间它仅仅维护一个连接。尽管这个类是线程安全的，但它应该被用于一个执行线程。 SingleClientConnManager对于同一路由的后续请求会尽量重用连接。而如果持久连接的路由不匹配连接请求的话，它也会关闭存在的连接 之后对给定路由再打开一个新的。如果连接已经被分配，将会抛出lStateException异常。

对于每个默认连接，HttpClient使用SingleClientConnManager。

2.8.4 连接池管理器

ThreadSafeClientConnManager 是一个复杂的实现来管理客户端连接池，它也可以从多个执行线程中服务连接请求。对每个基本的路由，连接都是池管理的。对于路由的请求，管理器在池中有可用 的持久性连接，将被从池中租赁连接服务，而不是创建一个新的连接。

ThreadSafeClientConnManager 维护每个基本路由的最大连接限制。每个默认的实现对每个给定路由将会创建不超过两个的并发连接，而总共也不会超过20个连接。对于很多真实的应用程序，这 个限制也证明很大的制约，特别是他们在服务中使用HTTP作为传输协议。连接限制，也可以使用HTTP参数来进行调整。

这个示例展示了连接池参数是如何来调整的：

HttpParams params = new BasicHttpParams();

// 增加最大连接到200

TotalConnections(params, 200);

// 增加每个路由的默认最大连接到20

ConnPerRouteBean connPerRoute = new ConnPerRouteBean(20);

// 对localhost:80增加最大连接到50

HttpHost localhost = new HttpHost("locahost", 80);

ForRoute(new HttpRoute(localhost), 50);

ConnectionsPerRoute(params, connPerRoute);

SchemeRegistry schemeRegistry = new SchemeRegistry();

er(

new Scheme("http", ketFactory(), 80));

er(

new Scheme("https", ketFactory(), 443));

ClientConnectionManager cm = new ThreadSafeClientConnManager(params,

schemeRegistry);

HttpClient httpClient = new DefaultHttpClient(cm, params);

2.8.5 连接管理器关闭

当一个HttpClient实例不再需要时，而且即将走出使用范围，那么关闭连接管理器来保证由管理器保持活动的所有连接被关闭，由连接分配的系统资源被释放是很重要的。

DefaultHttpClient httpclient = new DefaultHttpClient();

HttpGet httpget = new HttpGet("/");

HttpResponse response = e(httpget);

HttpEntity entity = ity();

n(tusLine());

if (entity != null) {

eContent();

}

nectionManager().shutdown();

2.9 连接管理参数

这些是可以用于定制标准HTTP连接管理器实现的参数：

'- t'：定义了当从ClientConnectionManager中检索ManagedClientConnection实 例时使用的毫秒级的超时时间。这个参数期望得到一个类型的值。如果这个参数没有被设置，连接请求就不会超时（无限大的超时时 间）。

'-per-route'：定义了每个路由连接的最大数量。这个限制由客户端连接管理器来解释，而且应用于独立的管理器实例。这个参数期望得到一个ConnPerRoute类型的值。

'-total'：定义了总共连接的最大数目。这个限制由客户端连接管理器来解释，而且应用于独立的管理器实例。这个参数期望得到一个r类型的值。

2.10 多线程执行请求

当配备连接池管理器时，比如ThreadSafeClientConnManager，HttpClient可以同时被用来执行多个请求，使用多线程执行。

ThreadSafeClientConnManager 将会分配基于它的配置的连接。如果对于给定路由的所有连接都被租出了，那么连接的请求将会阻塞，直到一个连接被释放回连接池。它可以通过设置 't'为一个正数来保证连接管理器不会在连接请求执行时无限期的被阻塞。如果连接请求不能在给定的时间 周期内被响应，将会抛出ConnectionPoolTimeoutException异常。

HttpParams params = new BasicHttpParams();

SchemeRegistry schemeRegistry = new SchemeRegistry();

er(

new Scheme("http", ketFactory(), 80));

ClientConnectionManager cm = new ThreadSafeClientConnManager(params,

schemeRegistry);

HttpClient httpClient = new DefaultHttpClient(cm, params);

// 执行GET方法的URI

String[] urisToGet = {

"/",

"/",

"/",

"/"

};

// 为每个URI创建一个线程

GetThread[] threads = new GetThread[];

for (int i = 0; i < ; i++) {

HttpGet httpget = new HttpGet(urisToGet[i]);

threads[i] = new GetThread(httpClient, httpget);

}

// 开始执行线程

for (int j = 0; j < ; j++) {

threads[j].start();

}

// 合并线程

for (int j = 0; j < ; j++) {

threads[j].join();

}

static class GetThread extends Thread {

private final HttpClient httpClient;

private final HttpContext context;

private final HttpGet httpget;

public GetThread(HttpClient httpClient, HttpGet httpget) {

ient = httpClient;

t = new BasicHttpContext();

t = httpget;

}

@Override

public void run() {

try {

HttpResponse response = e(t, t);

HttpEntity entity = ity();

if (entity != null) {

// 对实体做些有用的事情...

// 保证连接能释放回管理器

eContent();

}

} catch (Exception ex) {

();

}

}

}

2.11 连接收回策略

一 个经典的阻塞I/O模型的主要缺点是网络套接字仅当I/O操作阻塞时才可以响应I/O事件。当一个连接被释放返回管理器时，它可以被保持活动状态而却不能 监控套接字的状态和响应任何I/O事件。如果连接在服务器端关闭，那么客户端连接也不能去侦测连接状态中的变化和关闭本端的套接字去作出适当响应。

HttpClient 通过测试连接是否是过时的来尝试去减轻这个问题，这已经不再有效了，因为它已经在服务器端关闭了，之前使用执行HTTP请求的连接。过时的连接检查也并不 是100%的稳定，反而对每次请求执行还要增加10到30毫秒的开销。唯一可行的而不涉及到每个对空闲连接的套接字模型线程解决方案，是使用专用的监控线 程来收回因为长时间不活动

而被认为是过期的连接。监控线程可以周期地调用

ClientConnectionManager#closeExpiredConnections()方法来关闭所有过期的连接，从连接池中收回关闭的 连接。它也可以选择性调用ClientConnectionManager#closeIdleConnections()方法来关闭所有已经空闲超过给 定时间周期的连接。

public static class IdleConnectionMonitorThread extends Thread {

private final ClientConnectionManager connMgr;

private volatile boolean shutdown;

public IdleConnectionMonitorThread(ClientConnectionManager connMgr) {

super();

r = connMgr;

}

@Override

public void run() {

try {

while (!shutdown) {

synchronized (this) {

wait(5000);

// 关闭过期连接

xpiredConnections();

// 可选地，关闭空闲超过30秒的连接

dleConnections(30, S);

}

}

} catch (InterruptedException ex) {

// 终止

}

}

public void shutdown() {

shutdown = true;

synchronized (this) {

notifyAll();

}

}

}

2.12 连接保持活动的策略

HTTP 规范没有确定一个持久连接可能或应该保持活动多长时间。一些HTTP服务器使用非标准的头部信息Keep-Alive来告诉客户端它们想在服务器端保持连 接活动的周期秒数。如果这个信息可用，HttClient就会利用这个它。如果头部信息Keep-Alive在响应中不存在，HttpClient假设连 接无限期的保持活动。然而许多现实中的HTTP服务器配置了在特定不活动周期之后丢掉持久连接来保存系统资源，往往这是不通知客户端的。如果默认的策略证 明是过于乐观的，那么就会有人想提供一个定制的保持活动策略。

DefaultHttpClient httpclient = new DefaultHttpClient();

pAliveStrategy(new ConnectionKeepAliveStrategy() {

public long getKeepAliveDuration(HttpResponse response, HttpContext context) {

// 兑现'keep-alive'头部信息

HeaderElementIterator it = new BasicHeaderElementIterator(

Iterator(_KEEP_ALIVE));

while (t()) {

HeaderElement he = ement();

String param = e();

String value = ue();

if (value != null && IgnoreCase("timeout")) {

try {

return ong(value) * 1000;

} catch(NumberFormatException ignore) {

}

}

}

HttpHost target = (HttpHost) ribute(

_TARGET_HOST);

if ("".equalsIgnoreCase(tName())) {

// 只保持活动5秒

return 5 * 1000;

} else {

// 否则保持活动30秒

return 30 * 1000;

}

}

});

第三章 HTTP状态管理

原 始的HTTP是被设计为无状态的，面向请求/响应的协议，没有特殊规定有状态的，贯穿一些逻辑相关的请求/响应交换的会话。由于HTTP协议变得越来越普 及和受欢迎，越来越多的从前没有打算使用它的系统也开始为应用程序来使用它，比如作为电子商务应用程序的传输方式。因此，支持状态管理就变得非常必要了。

网 景公司，一度成为Web客户端和服务器软件开发者的领导方向，在它们基于专有规范的产品中实现了对HTTP状态管理的支持。之后，网景公司试图通过发布规 范草案来规范这种机制。它们的努力通过RFC标准跟踪促成了这些规范定义。然而，在很多应用程序中的状态管理仍然基于网景公司的草案而不兼容官方的规范。 很多主要的Web浏览器开发者觉得有必要保留那些极大促进标准片段应用程序的兼容性。

3.1 HTTP cookies

Cookie是HTTP代理和目标服务器可以交流保持会话的状态信息的令牌或短包。网景公司的工程师用它来指“魔法小甜饼”和粘住的名字。

HttpClient 使用Cookie接口来代表抽象的cookie令牌。在它的简单形式中HTTP的cookie几乎是名/值对。通常一个HTTP的cookie也包含一些 属性，比如版本号，合法的域名，指定cookie应用所在的源服务器URL子集的路径，cookie的最长有效时间。

SetCookie接口代表由源服务器发送给HTTP代理的响应中的头部信息Set-Cookie来维持一个对话状态。SetCookie2接口和指定的Set-Cookie2方法扩展了SetCookie。

SetCookie 接口和额外的如获取原始cookie属性的能力，就像它们由源服务器指定的客户端特定功能扩展了Cookie接口。这对生成Cookie头部很重要，因为 一些cookie规范需要。Cookie头部应该包含在Set-Cookie或Set-Cookie2头部中指定的特定属性。

3.1.1 Cookie版本

Cookie兼容网景公司的草案标准，但是版本0被认为是不符合官方规范的。符合标准的cookie的期望版本是1。HttpClient可以处理基于不同版本的cookie。

这里有一个重新创建网景公司草案cookie示例：

BasicClientCookie netscapeCookie = new BasicClientCookie("name", "value");

sion(0);

ain(".");

h("/");

这是一个重新创建标准cookie的示例。要注意符合标准的cookie必须保留由源服务器发送的所有属性：

BasicClientCookie stdCookie = new BasicClientCookie("name", "value");

sion(1);

ain(".");

h("/");

ure(true);

// 精确设置由服务器发送的属性

ribute(N_ATTR, "1");

ribute(_ATTR, ".");

这是一个重新创建Set-Cookie2兼容cookie的实例。要注意符合标准的cookie必须保留由源服务器发送的所有属性：

BasicClientCookie2 stdCookie = new BasicClientCookie2("name", "value");

sion(1);

ain(".");

ts(new int[] {80,8080});

h("/");

ure(true);

// 精确设置由服务器发送的属性

ribute(N_ATTR, "1");

ribute(_ATTR, ".");

ribute(_ATTR, "80,8080");

3.2 Cookie规范

CookieSpec接口代表了cookie管理的规范。Cookie管理规范希望如下几点：

解析的Set-Cookie规则还有可选的Set-Cookie2头部信息。

验证解析cookie的规则。

格式化给定主机的Cookie头部信息，原始端口和路径。

HttpClient附带了一些CookieSpec的实现：

网景公司草案：这个规范符合由网景通讯发布的原始草案规范。应当避免，除非有绝对的必

要去兼容遗留代码。

RFC 2109：官方HTTP状态管理规范并取代的老版本，被RFC 2965取代。

RFC 2965：官方HTTP状态管理规范。

浏览器兼容性：这个实现努力去密切模仿（mis）通用Web浏览器应用程序的实现。比如微软的Internet Explorer和Mozilla的FireFox浏览器。

最佳匹配：’Meta’（元）cookie规范采用了一些基于又HTTP响应发送的cookie格式的cookie策略。它基本上聚合了以上所有的实现到以一个类中。

强烈建议使用Best Match策略，让HttpClient在运行时基于执行上下文采用一些合适的兼容等级。

3.3 HTTP cookie和状态管理参数

这些是用于定制HTTP状态管理和独立的cookie规范行为的参数。

'- datepatterns'：定义了用于解析非标准的expires属性的合法日期格式。只是对兼容不符合规定的，仍然使用网景公司草案定义的 expires而不使用标准的max-age属性服务器需要。这个参数期望得到一个tion类型的值。集合元素必须是 类型，来兼容DateFormat的语法。如果这个参数没有被设置，那么默认的选择就 是CookieSpec实现规范的值。要注意这个参数的应用。

'- cookie-header'：定义了是否cookie应该强制到一个独立的Cookie请求头部信息中。否则，每个cookie就被当作分离的 Cookie头部信息来格式化。这个参数期望得到一个n类型的值。如果这个参数没有被设置，那么默认的选择就是

CookieSpec实现规范的值。要注意这个参数仅仅严格应用于cookie规范（RFC 2109和RFC

2965）。浏览器兼容性和网景公司草案策略将会放置所有的cookie到一个请求头部信息中。

'-policy'：定义了用于HTTP状态管理的cookie规范的名字。这个参数期望得到一个类型的值。如果这个参数没有被设置，那么合法的日期格式就是CookieSpec实现规范的值。

3.4 Cookie规范注册表

HttpClient使用CookieSpecRegistry类维护一个可用的cookie规范注册表。下面的规范对于每个默认都是注册过的：

兼容性：浏览器兼容性（宽松策略）。

网景：网景公司草案。

rfc2109：RFC 2109（过时的严格策略）。

rfc2965：RFC 2965（严格策略的标准符合）。

best-match：最佳匹配meta（元）策略。

3.5 选择cookie策略

Cookie策略可以在HTTP客户端被设置，如果需要，在HTTP请求级重写。

HttpClient httpclient = new DefaultHttpClient();

// 对每个默认的强制严格cookie策略

ams().setParameter(

_POLICY, _2965);

HttpGet httpget = new HttpGet("/");

// 对这个请求覆盖默认策略

ams().setParameter(

_POLICY, R_COMPATIBILITY);

3.6 定制cookie策略

为 了实现定制cookie策略，我们应该创建CookieSpec接口的定制实现类，创建一个CookieSpecFactory实现来创建和初始化定制实 现的实例并和HttpClient注册这个工厂。一旦定制实现被注册了，它可以和标准的cookie实现有相同的活性。

CookieSpecFactory csf = new CookieSpecFactory() {

public CookieSpec newInstance(HttpParams params) {

return new BrowserCompatSpec() {

@Override

public void validate(Cookie cookie, CookieOrigin origin)

throws MalformedCookieException {

// 这相当简单

}

};

}

};

DefaultHttpClient httpclient = new DefaultHttpClient();

kieSpecs().register("easy", csf);

ams().setParameter(

_POLICY, "easy");

3.7 Cookie持久化

HttpClient 可以和任意物理表示的实现了CookieStore接口的持久化cookie存储一起使用。默认的CookieStore实现称为 BasicClientCookie，这是凭借ist的一个简单实现。在BasicClientCookie对象中存储 的cookie当容器对象被垃圾回收机制回收时会丢失。如果需要，用户可以提供更复杂的实现。

DefaultHttpClient httpclient = new DefaultHttpClient();

// 创建一个本地的cookie store实例

CookieStore cookieStore = new MyCookieStore();

// 如果需要填充cookie

BasicClientCookie cookie = new BasicClientCookie("name", "value");

sion(0);

ain(".");

h("/");

kie(cookie);

// 设置存储

kieStore(cookieStore);

3.8 HTTP状态管理和执行上下文

在HTTP请求执行的过程中，HttpClient添加了下列和状态管理相关的对象到执行上下文中：

'spec-registry'：CookieSpecRegistry实例代表了实际的cookie规范注册表。这个属性的值设置在本地内容中，优先于默认的。

'-spec'：CookieSpec实例代表真实的cookie规范。

'-origin'：CookieOrigin实例代表了真实的源服务器的详细信息。

'-store'：CookieStore实例代表了真实的cookie存储。设置在本地内容中的这个属性的值优先于默认的。

本地的HttpContext对象可以被用来定制HTTP状态管理内容，先于请求执行或在请求执行之后检查它的状态：

HttpClient httpclient = new DefaultHttpClient();

HttpContext localContext = new BasicHttpContext();

HttpGet httpget = new HttpGet("localhost:8080/");

HttpResponse response = e(httpget, localContext);

CookieOrigin cookieOrigin = (CookieOrigin) ribute(

_ORIGIN);

n("Cookie origin: " + cookieOrigin);

CookieSpec cookieSpec = (CookieSpec) ribute(

_SPEC);

n("Cookie spec used: " + cookieSpec);

3.9 每个用户/线程的状态管理

我们可以使用独立的本地执行上下文来实现对每个用户（或每个线程）状态的管理。定义在本地内容中的cookie规范注册表和cookie存储将会优先于设置在HTTP客户端级别中默认的那些。

HttpClient httpclient = new DefaultHttpClient();

// 创建cookie store的本地实例

CookieStore cookieStore = new BasicCookieStore();

// 创建本地的HTTP内容

HttpContext localContext = new BasicHttpContext();

// 绑定定制的cookie store到本地内容中

ribute(_STORE, cookieStore);

HttpGet httpget = new HttpGet("/");

// 作为参数传递本地内容

HttpResponse response = e(httpget, localContext)

第三章 HTTP状态管理

原 始的HTTP是被设计为无状态的，面向请求/响应的协议，没有特殊规定有状态的，贯穿一些逻辑相关的请求/响应交换的会话。由于HTTP协议变得越来越普 及和受欢迎，越来越多的从前没有打算使用它的系统也开始为应用程序来使用它，比如作为电子商务应用程序的传输方式。因此，支持状态管理就变得非常必要了。

网 景公司，一度成为Web客户端和服务器软件开发者的领导方向，在它们基于专有规范的产品中实现了对HTTP状态管理的支持。之后，网景公司试图通过发布规 范草案来规范这种机制。它们的努力通过RFC标准跟踪促成了这些规范定义。然而，在很多应用程序中的状态管理仍然基于网景公司的草案而不兼容官方的规范。 很多主要的Web浏览器开发者觉得有必要保留那些极大促进标准片段应用程序的兼容性。

3.1 HTTP cookies

Cookie是HTTP代理和目标服务器可以交流保持会话的状态信息的令牌或短包。网景公司的工程师用它来指“魔法小甜饼”和粘住的名字。

HttpClient 使用Cookie接口来代表抽象的cookie令牌。在它的简单形式中HTTP的cookie几乎是名/值对。通常一个HTTP的cookie也包含一些 属性，比如版本号，合法的域名，指定cookie应用所在的源服务器URL子集的路径，cookie的最长有效时间。

SetCookie接口代表由源服务器发送给HTTP代理的响应中的头部信息Set-Cookie来维持一个对话状态。SetCookie2接口和指定的Set-Cookie2方法扩展了SetCookie。

SetCookie 接口和额外的如获取原始cookie属性的能力，就像它们由源服务器指定的客户端特定功能扩展了Cookie接口。这对生成Cookie头部很重要，因为 一些cookie规范需要。Cookie头部应该包含在Set-Cookie或Set-Cookie2头部中指定的特定属性。

3.1.1 Cookie版本

Cookie兼容网景公司的草案标准，但是版本0被认为是不符合官方规范的。符合标准的cookie的期望版本是1。HttpClient可以处理基于不同版本的cookie。

这里有一个重新创建网景公司草案cookie示例：

BasicClientCookie netscapeCookie = new BasicClientCookie("name", "value");

sion(0);

ain(".");

h("/");

这是一个重新创建标准cookie的示例。要注意符合标准的cookie必须保留由源服务器发送的所有属性：

BasicClientCookie stdCookie = new BasicClientCookie("name", "value");

sion(1);

ain(".");

h("/");

ure(true);

// 精确设置由服务器发送的属性

ribute(N_ATTR, "1");

ribute(_ATTR, ".");

这是一个重新创建Set-Cookie2兼容cookie的实例。要注意符合标准的cookie必须保留由源服务器发送的所有属性：

BasicClientCookie2 stdCookie = new BasicClientCookie2("name", "value");

sion(1);

ain(".");

ts(new int[] {80,8080});

h("/");

ure(true);

// 精确设置由服务器发送的属性

ribute(N_ATTR, "1");

ribute(_ATTR, ".");

ribute(_ATTR, "80,8080");

3.2 Cookie规范

CookieSpec接口代表了cookie管理的规范。Cookie管理规范希望如下几点：

解析的Set-Cookie规则还有可选的Set-Cookie2头部信息。

验证解析cookie的规则。

格式化给定主机的Cookie头部信息，原始端口和路径。

HttpClient附带了一些CookieSpec的实现：

网景公司草案：这个规范符合由网景通讯发布的原始草案规范。应当避免，除非有绝对的必要去兼容遗留代码。

RFC 2109：官方HTTP状态管理规范并取代的老版本，被RFC 2965取代。

RFC 2965：官方HTTP状态管理规范。

浏览器兼容性：这个实现努力去密切模仿（mis）通用Web浏览器应用程序的实现。比如微软的Internet Explorer和Mozilla的FireFox浏览器。

最佳匹配：’Meta’（元）cookie规范采用了一些基于又HTTP响应发送的cookie格式的cookie策略。它基本上聚合了以上所有的实现到以一个类中。

强烈建议使用Best Match策略，让HttpClient在运行时基于执行上下文采用一些合适的兼容等级。

3.3 HTTP cookie和状态管理参数

这些是用于定制HTTP状态管理和独立的cookie规范行为的参数。

'- datepatterns'：定义了用于解析非标准的expires属性的合法日期格式。只是对兼容不符合规定的，仍然使用网景公司草案定义的 expires而不使用标准的max-age属性服务器需要。这个参数期望得到一个tion类型的值。集合元素必须是 类型，来兼容DateFormat的语法。如果这个参数没有被设置，那么默认的选择就 是CookieSpec实现规范的值。要注意这个参数的应用。

'- cookie-header'：定义了是否cookie应该强制到一个独立的Cookie请求头部信息中。否则，每个cookie就被当作分离的 Cookie头部信息来格式化。这个参数期望得到一个n类型的值。如果这个参数没有被设置，那么默认的选择就是

CookieSpec实现规范的值。要注意这个参数仅仅严格应用于cookie规范（RFC 2109和RFC

2965）。浏览器兼容性和网景公司草案策略将会放置所有的cookie到一个请求头部信息中。

'-policy'：定义了用于HTTP状态管理的cookie规范的名字。这个参数期望得到一个类型的值。如果这个参数没有被设置，那么合法的日期格式就是CookieSpec实现规范的值。

3.4 Cookie规范注册表

HttpClient使用CookieSpecRegistry类维护一个可用的cookie规范注册表。下面的规范对于每个默认都是注册过的：

兼容性：浏览器兼容性（宽松策略）。

网景：网景公司草案。

rfc2109：RFC 2109（过时的严格策略）。

rfc2965：RFC 2965（严格策略的标准符合）。

best-match：最佳匹配meta（元）策略。

3.5 选择cookie策略

Cookie策略可以在HTTP客户端被设置，如果需要，在HTTP请求级重写。

HttpClient httpclient = new DefaultHttpClient();

// 对每个默认的强制严格cookie策略

ams().setParameter(

_POLICY, _2965);

HttpGet httpget = new HttpGet("/");

// 对这个请求覆盖默认策略

ams().setParameter(

_POLICY, R_COMPATIBILITY);

3.6 定制cookie策略

为 了实现定制cookie策略，我们应该创建CookieSpec接口的定制实现类，创建一个CookieSpecFactory实现来创建和初始化定制实 现的实例并和HttpClient注册这个工厂。一旦定制实现被注册了，它可以和标准的cookie实现有相同的活性。

CookieSpecFactory csf = new CookieSpecFactory() {

public CookieSpec newInstance(HttpParams params) {

return new BrowserCompatSpec() {

@Override

public void validate(Cookie cookie, CookieOrigin origin)

throws MalformedCookieException {

// 这相当简单

}

};

}

};

DefaultHttpClient httpclient = new DefaultHttpClient();

kieSpecs().register("easy", csf);

ams().setParameter(

_POLICY, "easy");

3.7 Cookie持久化

HttpClient 可以和任意物理表示的实现了CookieStore接口的持久化cookie存储一起使用。默认的CookieStore实现称为 BasicClientCookie，这是凭借ist的一个简单实现。在BasicClientCookie对象中存储 的cookie当容器对象被垃圾回收机制回收时会丢失。如果需要，用户可以提供更复杂的实现。

DefaultHttpClient httpclient = new DefaultHttpClient();

// 创建一个本地的cookie store实例

CookieStore cookieStore = new MyCookieStore();

// 如果需要填充cookie

BasicClientCookie cookie = new BasicClientCookie("name", "value");

sion(0);

ain(".");

h("/");

kie(cookie);

// 设置存储

kieStore(cookieStore);

3.8 HTTP状态管理和执行上下文

在HTTP请求执行的过程中，HttpClient添加了下列和状态管理相关的对象到执行上下文中：

'spec-registry'：CookieSpecRegistry实例代表了实际的cookie规范注册表。这个属性的值设置在本地内容中，优先于默认的。

'-spec'：CookieSpec实例代表真实的cookie规范。

'-origin'：CookieOrigin实例代表了真实的源服务器的详细信息。

'-store'：CookieStore实例代表了真实的cookie存储。设置在本地内容中的这个属性的值优先于默认的。

本地的HttpContext对象可以被用来定制HTTP状态管理内容，先于请求执行或在请求执行之后检查它的状态：

HttpClient httpclient = new DefaultHttpClient();

HttpContext localContext = new BasicHttpContext();

HttpGet httpget = new HttpGet("localhost:8080/");

HttpResponse response = e(httpget, localContext);

CookieOrigin cookieOrigin = (CookieOrigin) ribute(

_ORIGIN);

n("Cookie origin: " + cookieOrigin);

CookieSpec cookieSpec = (CookieSpec) ribute(

_SPEC);

n("Cookie spec used: " + cookieSpec);

3.9 每个用户/线程的状态管理

我们可以使用独立的本地执行上下文来实现对每个用户（或每个线程）状态的管理。定义在本地内容中的cookie规范注册表和cookie存储将会优先于设置在HTTP客户端级别中默认的那些。

HttpClient httpclient = new DefaultHttpClient();

// 创建cookie store的本地实例

CookieStore cookieStore = new BasicCookieStore();

// 创建本地的HTTP内容

HttpContext localContext = new BasicHttpContext();

// 绑定定制的cookie store到本地内容中

ribute(_STORE, cookieStore);

HttpGet httpget = new HttpGet("/");

// 作为参数传递本地内容

HttpResponse response = e(httpget, localContext)

第五章 HTTP客户端服务

5.1 HttpClient门面

HttpClient接口代表了最重要的HTTP请求执行的契约。它没有在请求执行处理上强加限制或特殊细节，而在连接管理，状态管理，认证和处理重定向到具体实现上留下了细节。这应该使得很容易使用额外的功能，比如响应内容缓存来装饰接口。

DefaultHttpClient 是HttpClient接口的默认实现。这个类扮演了很多特殊用户程序或策略接口实现负责处理特定HTTP协议方面，比如重定向到处理认证或做出关于连接 持久化和保持活动的持续时间决定的门面。这使得用户可以选择使用定制，具体程序等来替换某些方面默认实现。

DefaultHttpClient httpclient = new DefaultHttpClient();

pAliveStrategy(new DefaultConnectionKeepAliveStrategy() {

@Override

public long getKeepAliveDuration(HttpResponse response,

HttpContext context) {

long keepAlive = pAliveDuration(response, context);

if (keepAlive == -1) {

// 如果keep-alive值没有由服务器明确设置，那么保持连接持续5秒。

keepAlive = 5000;

}

return keepAlive;

}

});

DefaultHttpClient 也维护一组协议拦截器，意在处理即将离开的请求和即将到达的响应，而且提供管理那些拦截器的方法。新的协议拦截器可以被引入到协议处理器链中，或在需要时

从中移除。内部的协议拦截器存储在一个简单的ist中。它们以被加入到list中的自然顺序来执行。

DefaultHttpClient httpclient = new DefaultHttpClient();

RequestInterceptorByClass();

uestInterceptor(new HttpRequestInterceptor() {

public void process(

HttpRequest request, HttpContext context)

throws HttpException, IOException {

der(_AGENT, "My-own-client");

}

});

DefaultHttpClient 是线程安全的。建议相同的这个类的实例被重用于多个请求的执行。当一个DefaultHttpClient实例不再需要而且要脱离范围时，和它关联的连接 管理器必须调用ClientConnectionManager#shutdown()方法关闭。

HttpClient httpclient = new DefaultHttpClient();

// 做些有用的事

nectionManager().shutdown();

5.2 HttpClient参数

这些是可以用于定制默认HttpClient实现行为的参数：

'-redirects'：定义了重定向是否应该自动处理。这个参数期望得到一个n类型的值。如果这个参数没有被设置，HttpClient将会自动处理重定向。

'- relative-redirect'：定义了是否相对的重定向应该被拒绝。HTTP规范需要位置值是一个绝对URI。这个参数期望得到一个 n类型的值。如果这个参数没有被设置，那么就允许相对重定向。

'- redirects'：定义了要遵循重定向的最大数量。这个重定向数字的限制意在防止由破碎的服务器端脚本引发的死循环。这个参数期望得到一个 r类型的值。如果这个参数没有被设置，那么只允许不多余100次重定向。

'- circular-redirects'：定义环形重定向（重定向到相同路径）是否被允许。

HTTP规范在环形重定向没有足够清晰的允许表述，因此这作为 可选的是可以开启的。这个参数期望得到一个n类型的值。如果这个参数没有被设置，那么环形重定向就不允许。

'tion- y-class-name'：定义了默认的ClientConnectionManager实现的类型。这个参数期望得到一 个类型的值。如果这个参数没有被设置，对于每个默认的将使用SingleClientConnManager。

'l-host'：定义了在头部信息Host中使用的虚拟主机名称，来代替物理主机名称。这个参数期望得到一个HttpHost类型的值。如果这个参数没有被设置，那么将会使用目标主机的名称或IP地址。

't-headers'：定义了每次请求默认发送的头部信息。这个参数期望得到一个包含Header对象的tion类型值。

't-host'：定义了默认主机。如果目标主机没有在请求URI（相对URI）中明确指定，那么就使用默认值。这个参数期望得到一个HttpHost类型的值。

5.3 自动重定向处理

HttpClient处理所有类型的自动重定向，除了那些由HTTP规范明令禁止的，比如需要用户干预的。参考其它（状态码303）POST和PUT请求重定向转换为由HTTP规范需要的GET请求。

5.4 HTTP客户端和执行上下文

DefaultHttpClient 将HTTP请求视为不变的对象，也从来不会假定在请求执行期间改变。相反，它创建了一个原请求对象私有的可变副本，副本的属性可以基于执行上下文来更新。 因此，如目标主键和请求URI的final类型的请求参数可以在请求执行之后，由检查本地HTTP上下文来决定。

DefaultHttpClient httpclient = new DefaultHttpClient();

HttpContext localContext = new BasicHttpContext();

HttpGet httpget = new HttpGet("localhost:8080/");

HttpResponse response = e(httpget, localContext);

HttpHost target = (HttpHost) ribute(

_TARGET_HOST);

HttpUriRequest req = (HttpUriRequest) ribute(

_REQUEST);

n("Target host: " + target);

n("Final request URI: " + ());

n("Final request method: " + hod());

第六章 高级主题

6.1 自定义客户端连接

在特定条件下，也许需要来定制HTTP报文通过线路传递，越过了可能使用的HTTP参数来处理非标准不兼容行为的方式。比如，对于Web爬虫，它可能需要强制HttpClient接受格式错误的响应头部信息，来抢救报文的内容。

通常插入一个自定义的报文解析器的过程或定制连接实现需要几个步骤：

提供一个自定义LineParser/LineFormatter接口实现。如果需要，实现报文解析/格式化逻辑。

class MyLineParser extends BasicLineParser {

@Override

public Header parseHeader(

final CharArrayBuffer buffer) throws ParseException {

try {

return eader(buffer);

} catch (ParseException ex) {

// 压制ParseException异常

return new BasicHeader("invalid", ng());

}

}

}

提过一个自定义的OperatedClientConnection实现。替换需要自定义的默认请求/响应解析器，请求/响应格式化器。如果需要，实现不同的报文写入/读取代码。

class MyClientConnection extends DefaultClientConnection {

@Override

protected HttpMessageParser createResponseParser(

final SessionInputBuffer buffer,

final HttpResponseFactory responseFactory,

final HttpParams params) {

return new DefaultResponseParser(buffer,

new MyLineParser(),responseFactory,params);

}

}

为了创建新类的连接，提供一个自定义的ClientConnectionOperator接口实现。如果需要，实现不同的套接字初始化代码。

class MyClientConnectionOperator extends

DefaultClientConnectionOperator {

public MyClientConnectionOperator(

final SchemeRegistry sr) {

super(sr);

}

@Override

public OperatedClientConnection createConnection() {

return new MyClientConnection();

}

}

为了创建新类的连接操作，提供自定义的ClientConnectionManager接口实现。

class MyClientConnManager extends SingleClientConnManager {

public MyClientConnManager(

final HttpParams params,

final SchemeRegistry sr) {

super(params, sr);

}

@Override

protected ClientConnectionOperator createConnectionOperator(

final SchemeRegistry sr) {

return new MyClientConnectionOperator(sr);

}

}

6.2 有状态的HTTP连接

HTTP 规范假设session状态信息通常是以HTTP cookie格式嵌入在HTTP报文中的，因此HTTP连接通常是无状态的，这个假设在现实生活中通常是不对的。也有一些情况，当HTTP连接使用特定的 用户标识或特定的安全上下文来创建时，因此不能和其它用户共享，只能由该用户重用。这样的有状态的HTTP连接的示例就是NTLM认证连接和使用客户端证 书认证的SSL连接。

6.2.1 用户令牌处理器

HttpClient 依赖UserTokenHandler接口来决定给定的执行上下文是否是用户指定的。如果这个上下文是用户指定的或者如果上下文没有包含任何资源或关于当 前用户指定详情而是null，令牌对象由这个处理器返回，期望唯一地标识当前的用户。用户令牌将被用来保证用户指定资源不会和其它用户来共享或重用。

如 果它可以从给定的执行上下文中来获得，UserTokenHandler接口的默认实现是使用主类的一个实例来代表HTTP连接的状态对象。 UserTokenHandler将会使用基于如NTLM或开启的客户端认证SSL会话认证模式的用户的主连接。如果二者都不可用，那么就不会返回令牌。

如果默认的不能满足它们的需要，用户可以提供一个自定义的实现：

DefaultHttpClient httpclient = new DefaultHttpClient();

rTokenHandler(new UserTokenHandler() {

public Object getUserToken(HttpContext context) {

return ribute("my-token");

}

});

6.2.2 用户令牌和执行上下文

在HTTP请求执行的过程中，HttpClient添加了下列和用户标识相关的对象到执行上下文中：

'-token'：对象实例代表真实的用户标识，通常期望Principle接口的实例。

我们可以在请求被执行后，通过检查本地HTTP上下文的内容，发现是否用于执行请求的连接是有状态的。

DefaultHttpClient httpclient = new DefaultHttpClient();

HttpContext localContext = new BasicHttpContext();

HttpGet httpget = new HttpGet("localhost:8080/");

HttpResponse response = e(httpget, localContext);

HttpEntity entity = ity();

if (entity != null) {

eContent();

}

Object userToken = ribute(_TOKEN);

n(userToken);

6.2.2.1 持久化有状态的连接

请注意带有状态对象的持久化连接仅当请求被执行时，相同状态对象被绑定到执行上下文时可以被重用。所以，保证相同上下文重用于执行随后的相同用户，或用户令牌绑定到之前请求执行上下文的HTTP请求是很重要的。

DefaultHttpClient httpclient = new DefaultHttpClient();

HttpContext localContext1 = new BasicHttpContext();

HttpGet httpget1 = new HttpGet("localhost:8080/");

HttpResponse response1 = e(httpget1, localContext1);

HttpEntity entity1 = ity();

if (entity1 != null) {

eContent();

}

Principal principal = (Principal) ribute(

_TOKEN);

HttpContext localContext2 = new BasicHttpContext();

ribute(_TOKEN, principal);

HttpGet httpget2 = new HttpGet("localhost:8080/");

HttpResponse response2 = e(httpget2, localContext2);

HttpEntity entity2 = ity();

if (entity2 != null) {

eContent();

}