HttpClient 介绍

1、HttpClient的功效

基于标准 ，纯真java，实现了http1.0和1.1。

在一个可扩张的OO框架内，实现了HTTP的整个 法子 (GET, POST,
PUT, DELETE, HEAD, OPTIONS, and TRACE)

支撑 HTTPS(ssl上的HTTP)的加密操作

透明地穿过HTTP代理建立 连接

通过CONNECT法子 ，利用 通过建立 穿过HTTP代理的HTTPS连接

利用 本地Java socket，透明地穿过SOCKS(版本5和4）代理建立 连接

支撑 利用 Basic、Digest和NTLM加密的认证

支撑 用于上传大文件的Multi-Part表单POST法子

插件式安全socket实现，易于应用 第三方的解决方案

连接 收 理，支撑 多线程利用 ，支撑 设定单个主机总连接 和最高连接 数量,主动 检测和关闭失效连接

直接将恳求 信息流送到服务器的端口

直接读取从服务器的端口送出的应答信息

支撑 HTTP/1.0中用KeepAlive和HTTP/1.1中用persistance设置的持久连接

直接造访 由服务器送出的应答代码和头部信息

可设置连接 超时光阴

HttpMethods 实现Command Pattern，以容许 并行恳求 或高效连接 复用

遵守 the Apache Software License协议 ，源码免费可得

2、准备 工作

　　对jre1.3.*，如果要HttpClient支撑 https，则需要 下载并安装jsse和jce.安装的步骤如下：
1)下载jsse和jce.
2)反省 CLASSPATH中没有与jsse和jce相干 的jar包
3)将 US_export_policy.jar、local_policy.jar、jsse.jar、jnet.jar、jce1_2_x.jar、sunjce_provider.jar、jcert.jar复制到目录：
UNIX:$JDK_HOME/jre/lib/ext
Windows:%JDK_HOME%\jre\lib\ext
4)修正 下述目录下的java.security文件。
UNIX:$JDK_HOME/jre/lib/security/
Windows:%JDK_HOME%\jre\lib\security\
5)
将
#
# List of providers and their preference orders:
#
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.rsajca.Provider
改为：
#
# List of providers and their preference orders:
#
security.provider.1=com.sun.crypto.provider.SunJCE
security.provider.2=sun.security.provider.Sun
security.provider.3=com.sun.rsajca.Provider
security.provider.4=com.sun.net.ssl.internal.ssl.Provider

　　HttpClient还请求 安装commons-logging，下面跟httpclient一块安装。

3、取得源码

cvs -d :pserver:[e-mail]:/home/cvspublic login
password: anoncvs
cvs -d :pserver:[e-mail]:/home/cvspublic checkout jakarta-commons/logging
cvs -d :pserver:[e-mail]:/home/cvspublic checkout jakarta-commons/httpclient

　　编译：
cd jakarta-commons/logging
ant dist
cp dis/*.jar ../httpclient/lib/
cd ../httpclient
ant dist

4、应用 HttpClient编程的根基步聚

创立 HttpClient 的一个实例.

创立 某个法子 （DeleteMethod，EntityEnclosingMethod，ExpectContinueMethod，GetMethod，HeadMethod，MultipartPostMethod，OptionsMethod，PostMethod，PutMethod，TraceMethod） 的一个实例，一般可用要目标 URL为参数。

让 HttpClient 履行 这个法子 .

读取应答信息.

释放连接 .

处理 应答.

　　在履行 法子 的历程 中，有两种异常，一种是HttpRecoverableException，表现 偶然性差错 产生 ，一般再试可能成功 ，另一种是IOException，严重差错 。
　　这儿有这个教程中的一个例程，可以下载。
5、认证

　　HttpClient三种不同的认证方案 : Basic, Digest and NTLM. 这些方案 可用于服务器或代理对客户端的认证，简称服务器认证或代理认证。
1)服务器认证(Server Authentication)
　　HttpClient处理 服务器认证几乎是透明的，仅需要 开发人员供给 登录信息(login credentials)。登录信息保存 在HttpState类的实例中，可以通过 setCredentials(String realm, Credentials cred)和getCredentials(String realm)来获取或设置。注意，设定对非特定站点造访 所需要 的登录信息，将realm参数置为null. HttpClient内建的主动 认证，可以通过HttpMethod类的setDoAuthentication(boolean doAuthentication)法子 关闭，而且这次关闭只影响HttpMethod当前的实例。
　　抢先认证(Preemptive Authentication)可以通过下述法子 打开.
client.getState().setAuthenticationPreemptive(true);
　　在这种模式时，HttpClient会主动 将basic认证应答信息传给服务器，即使在某种情况 下服务器可能返回认证失败的应答，这样做首要是为了减少连接 的建立 。为使每个新建的 HttpState实例都执行抢先认证，可以如下设置系统 属性。
setSystemProperty(Authenticator.PREEMPTIVE_PROPERTY, "true");

Httpclient实现的抢先认证遵守 rfc2617.
2)代理认证(proxy authentication)
　　除了登录信息需单独寄放 以外，代理认证与服务器认证几乎一致。用 setProxyCredentials(String realm, Credentials cred)和 getProxyCredentials(String realm)设、取登录信息。
3)认证方案 (authentication schemes)
　　Basic
　　是HTTP中规定最早的也是最兼容()的方案 ，遗憾的是也是最不安全的一个方案 ，因为它以明码传送用户名和密码。它请求 一个UsernamePasswordCredentials实例，可以指定服务器端的造访 空间或采纳 默认的登录信息。
　　Digest
　　是在HTTP1.1中增加的一个方案 ，虽然不如Basic得到的软件支撑 多，但还是有广泛 的应用 。Digest方案 比Basic方案 安全得多，因它根本 就不通过网络传送实际的密码，传送的是利用 这个密码对从服务器传来的一个随机数(nonce)的加密串。它请求 一个UsernamePasswordCredentials实例，可以指定服务器端的造访 空间或采纳 默认的登录信息。
　　NTLM
　　这是HttpClient支撑 的最繁杂 的认证协议 。它M$设计的一个私有协议 ，没有公开的规范阐明 。一起头由于设计的缺点 ，NTLM的安全性比Digest差，后来经过一个ServicePack补丁后，安全性则对比 Digest高。NTLM需要 一个NTCredentials实例. 注意，由于NTLM不应用 造访 空间(realms)的概念，HttpClient利用 服务器的域名作造访 空间的名字。还需要 注意，供给 给 NTCredentials的用户名，不要用域名的前缀 - 如: "adrian" 是正确 的，而 "DOMAIN\adrian" 则是错的.
　　NTLM认证的工作机制与basic和digest有很大的区别 。这些区别 一般由HttpClient处理 ，但了解这些区别 有助避免在应用 NTLM认证时出现差错 。

从HttpClientAPI的角度来看，NTLM与其它认证法子 一样的工作，区别 是需要 供给 'NTCredentials'实例而不是'UsernamePasswordCredentials'(其实，前者只是扩张了后者)

对NTLM认证，造访 空间是连接 到的机器的域名，这对多域名主时机 有一些麻烦.只有HttpClient连接 中指定的域名才是认证用的域名。建议将realm设为null以应用 默认的设置。

NTLM只是认证了一个连接 而不是一恳求 ，所以每当一个新的连接 建立 就要进行一次认证，且在认证的历程 中维持 连接 是非常首要 的。 因此，NTLM不能同时用于代理认证和服务器认证，也不能用于http1.0连接 或服务器不支撑 持久连接 的情况 。
6、重定向

　　由于技巧 限制，以及为保证2.0发布 版API的稳固 ，HttpClient还不能主动 处重定向，但对重定向到同一主机、同一端口且采纳 同一协议 的情况 HttpClient可以支撑 。不能主动 的处理 的情况 ，包孕需要 人工交互的情况 ，或越过 httpclient的能力 。
　　当服务器重 定向指令指到不同的主机时，HttpClient只是简略 地将重定向状态 码作为应答状态 。所有的300到399（包孕 两端）的返回码，都表现 是重定向应答。常见的有：

301 永久移动. HttpStatus.SC_MOVED_PERMANENTLY

302 临时移动. HttpStatus.SC_MOVED_TEMPORARILY

303 See Other. HttpStatus.SC_SEE_OTHER

307 临时重定向. HttpStatus.SC_TEMPORARY_REDIRECT

　　当收到简略 的重定向时，程序应从HttpMethod对象中抽取新的URL并将其下载。另外,限制一下重定向次数是个好的主见 ，这可以避免递归循环。新的URL可以从头字段Location中抽取，如下：
String redirectLocation;
Header locationHeader = method.getResponseHeader("location");
if (locationHeader != null) {
redirectLocation = locationHeader.getValue();
} else {
// The response is invalid and did not provide the new location for
// the resource. Report an error or possibly handle the response
// like a 404 Not Found error.
}

特别 重定向：

300 多重选择. HttpStatus.SC_MULTIPLE_CHOICES

304 没有修正. HttpStatus.SC_NO T_MODIFIED

305 应用 代理. HttpStatus.SC_USE_PROXY

 

7、字符编码(character encoding)

　　一个HTTP协议 的恳求 或应答的头部(在http协议 中，数据包分为两部分，一部分是头部，由一些名值对构成，一部分是主体(body)，是真正传办理的数据（如HTML页面等）），必须 以US-ASCII编码，这是因为头部不传数据而只描绘被要传输的数据的一些信息，一个例外是cookie，它是数据但是通过甚部进行传输的，所以它也要用US-ASCII编码。
　　HTTP数据包的主体部分，可以用任何一种法子 进行编码，默认是ISO-8859-1，具体可以用头部字段Content-Type指定。可以利用 addRequestHeader法子 ，设定编码法子 ；用 getResponseCharSet取得编码法子 。对HTML或XML等类型的文档，它们的本身的Content-Type也可以指定编码法子 ，首要区分两者的作用领域以得到正确 凿 的解码。
　　URL的编码标准 ，由RFC1738指定为，只能是由可打印8位/字节的us-ascii字符组成，80-ff不是us-ascii字符，而00-1F是把持 字符，这两个区域中用的字符都须加以编码(encoded)。
　　
8、Cookies

　　 HttpClient能主动 管理cookie,包孕容许 服务器设置cookie并在需要 的时候主动 将cookie返回服务器，它也支撑 手工设置cookie后发送到服务器端。不幸的是，对如何处理 cookie，有几个规范互相冲突：Netscape Cookie 草案, RFC2109, RFC2965，而且还有很大数量的软件商的cookie实现不遵守 任何规范. 为了处理 这种状态 ，HttpClient供给 了策略驱动的cookie管理法子 。HttpClient支撑 的cookie规范有：
Netscape cookie草案，是最早的cookie规范，基于rfc2109。尽管这个规范与rc2109有较大的区别 ，这样做可以与一些服务器兼容。

rfc2109，是w3c发布 的第一个官方cookie规范。理论上讲，所有的服务器在处理 cookie(版本1)时，都要遵守 此规范，正因如此，HttpClient将其设为默认的规范。遗憾的是，这个规范太严峻 了，以致很多服务器不正确 的实行 了该规范或仍在作用Netscape规范。在这种情况 下，应应用 兼容规范。

兼容性规范，设计用来兼容尽可能多的服务器，即使它们并没有遵守 标准 规范。当解析cookie出现问题时，应考虑 采纳 兼容性规范。

　　 RFC2965规范暂时没有被HttpClient支撑 （在以后的版本为会加上），它定义了cookie版本2，并阐明 了版本1cookie的不足，RFC2965有意有久代替 rfc2109.
　　在HttpClient中，有两种法子 来指定cookie规范的应用 ，
HttpClient client = new HttpClient();
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
这种法子 设置的规范只对当前的HttpState有效，参数可取值CookiePolicy.COMPATIBILITY，CookiePolicy.NETSCAPE_DRAFT或CookiePolicy.RFC2109。

System.setProperty("apache.commons.httpclient.cookiespec", "COMPATIBILITY");
此法指的规范，对以后每个新建立 的HttpState对象都有效，参数可取值"COMPATIBILITY","NETSCAPE_DRAFT"或"RFC2109"。
　　常有不能解析cookie的问题，但替换到兼容规范大都能解决。

　　
9、应用 HttpClient遇到问题怎么办

用一个涉猎 器造访 服务器，以确认服务器应答正常

如果在使代理，关掉代理试试

另找一个服务器来试试（如果运行着不同的服务器软件更好）

反省 代码是否按教程中讲的思路编写

设置log级别为debug，找出问题出现的原因

打开wiretrace，来追踪客户端与服务器的通信 ，以确凿 问题出现在什么处所

用telnet或netcat手工将信息发送到服务器，适宜于猜测已经找到了原因而进行实验 时

将netcat以监听法子 运行，用作服务器以反省 httpclient如何处理 应答的。

利用 最新的httpclient试试，bug可能在最新的版本中修复了

向邮件列表求赞助

向bugzilla报告bug.

10、SSL

　　借助Java Secure Socket Extension (JSSE)，HttpClient全面支撑 Secure Sockets Layer (SSL)或IETF Transport Layer Security (TLS)协议 上的HTTP。JSSE已经jre1.4及以后的版本中，以前的版本则需要 手工安装设置，具体历程 参见Sun网站或本学习笔记。
　　HttpClient中应用 SSL非常简略 ，参考下面两个例子:
HttpClient httpclient = new HttpClient();
GetMethod httpget = new GetMethod("");
httpclient.executeMethod(httpget);
System.out.println(httpget.getStatusLine().toString());
，如果通过需要 授权的代理，则如下：
HttpClient httpclient = new HttpClient();
httpclient.getHostConfiguration().setProxy("myproxyhost", 8080);
httpclient.getState().setProxyCredentials("my-proxy-realm", " myproxyhost",
new UsernamePasswordCredentials("my-proxy-username", "my-proxy-password"));
GetMethod httpget = new GetMethod("");
httpclient.executeMethod(httpget);
System.out.println(httpget.getStatusLine().toString());

　　在HttpClient中定制SSL的步骤如下：

供给 了一个实现了org.apache.commons.httpclient.protocol.SecureProtocolSocketFactory接口的socket factory。这个 socket factory负责打一个到服务器的端口，应用 标准 的或第三方的SSL函数库，并进行象连接 握手等初始化操作。通常情况 下，这个初始化操作在端口被创立 时主动 进行的。

实例化一个org.apache.commons.httpclient.protocol.Protocol对象。创立 这个实例时，需要 一个合法的协议 类型(如https)，一个定制的socket factory，和一个默认的端中号(如https的443端口).
Protocol myhttps = new Protocol("https", new MySSLSocketFactory(), 443);
然后，这个实例可被设置为协议 的处理 器。
HttpClient httpclient = new HttpClient();
httpclient.getHostConfiguration().setHost("", 443, myhttps);
GetMethod httpget = new GetMethod("/");
httpclient.executeMethod(httpget);

通过调用Protocol.registerProtocol法子 ，将此定制的实例，注册为某一特定协议 的默认的处理 器。由此，可以很方便 地定制自己的协议 类型(如myhttps)。
Protocol.registerProtocol("myhttps",
new Protocol("https", new MySSLSocketFactory(), 9443));
...
HttpClient httpclient = new HttpClient();
GetMethod httpget = new GetMethod("myhttps://www.whatever.com/");
httpclient.executeMethod(httpget);
如果想用自己定制的处理 器代替 https默认的处理 器，只需要 将其注册为"https"即可。
Protocol.registerProtocol("https",
new Protocol("https", new MySSLSocketFactory(), 443));
HttpClient httpclient = new HttpClient();
GetMethod httpget = new GetMethod("");
httpclient.executeMethod(httpget);

　　已知的限制和问题

继续 的SSL连接 在Sun的低于1.4JVM上不能工作，这是由于JVM的bug造成。

通过代理造访 服务器时，非抢先认证（ Non-preemptive authentication）会失败，这是由于HttpClient的设计缺点 造成的，以后的版本中会修正 。

　　遇到问题的处理
　　很多问题，特别 是在jvm低于1.4时，是由jsse的安装造成的。
　　下面的代码，可作为最终的检测手法 。

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.Writer;
import java.net.Socket;
import javax.net.ssl.SSLSocketFactory;

public class Test {

public static final String TARGET_HTTPS_SERVER = "";
public static final int TARGET_HTTPS_PORT = 443;

public static void main(String[] args) throws Exception {

Socket socket = SSLSocketFactory.getDefault().
createSocket(TARGET_HTTPS_SERVER, TARGET_HTTPS_PORT);
try {
Writer out = new OutputStreamWriter(
socket.getOutputStream(), "ISO-8859-1");
out.write("GET / HTTP/1.1\r\n");
out.write("Host: " + TARGET_HTTPS_SERVER + ":" +
TARGET_HTTPS_PORT + "\r\n");
out.write("Agent: SSL-TEST\r\n");
out.write("\r\n");
out.flush();
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream(), "ISO-8859-1"));
String line = null;
while ((line = in.readLine()) != null) {
System.out.println(line);
}
} finally {
socket.close();
}
}
}

　　
11、httpclient的多线程处理

　　应用 多线程的首要目标 ，是为了实现并行的下载。在httpclient运行的历程 中，每个http协议 的法子 ，应用 一个HttpConnection实例。由于连接 是一种有限的资源，每个连接 在某一时刻只能供一个线程和法子 应用 ，所以需要 确保在需要 时正确 地分配连接 。HttpClient采纳 了一种类似 jdbc连接 池的法子 来管理连接 ，这个管理工作由 MultiThreadedHttpConnectionManager完成。
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
HttpClient client = new HttpClient(connectionManager);
此是，client可以在多个线程中被用来履行 多个法子 。每次调用HttpClient.executeMethod() 法子 ，都会去链吸收理器申请一个连接 实例，申请成功 这个链接实例被签出(checkout)，随之在链接应用 完后必须 归还管理器。管理器支撑 两个设置： maxConnectionsPerHost 每个主机的最大并行链接数，默觉得 2
maxTotalConnections 客户端总并行链接最大数，默觉得 20

　　管理器重 新利用 链接时，采纳早归还者先重用的法子 （least recently used approach）。
　　由于是应用 HttpClient的程序而不是HttpClient本身来读取应答包的主体，所以HttpClient无法抉择 什么光阴 连接 不再应用 了，这也就请求 在读完应答包的主体后必须 手工显式地调用releaseConnection()来释放申请的链接。
MultiThreadedHttpConnectionManager connectionManager = new MultiThreadedHttpConnectionManager();
HttpClient client = new HttpClient(connectionManager);
...
// 在某个线程中。
GetMethod get = new GetMethod("");
try {
client.executeMethod(get);
// print response to stdout
System.out.println(get.getResponseBodyAsStream());
} finally {
// be sure the connection is released back to the connection
// manager
get.releaseConnection();
}
对每一个HttpClient.executeMethod须有一个method.releaseConnection()与之匹配.
12、HTTP法子

　　HttpClient支撑 的HTTP法子 有8种，下面分述之。

　　1、Options

　　HTTP法子 Options用来向服务器发送恳求 ，盼望 获得针对由恳求 URL(request url)标记 的资源在恳求 /应答的通信 历程 可以应用 的功效 选项。通过这个法子 ，客户端可以在采纳具体举动 之前，就可对某一资源抉择 采纳什么动作和/或以及一些必要条件，或者领会 服务器供给 的功效 。这个法子 最范例的利用 ，就是用来获取服务器支撑 哪些HTTP法子 。
　　HttpClient中有一个类叫OptionsMethod，来支撑 这个HTTP法子 ，利用 这个类的getAllowedMethods法子 ，就可以很简略 地实现上述的范例利用 。

OptionsMethod options = new OptionsMethod("");
// 履行 法子 并做相应的异常处理
...
Enumeration allowedMethods = options.getAllowedMethods();
options.releaseConnection();

　　2、Get

　　 HTTP法子 GET用来取回恳求 URI（request-URI）标记 的任何信息（以实体(entity)的情势 ），"get"这个单词本意就是”获取“的意思。如果恳求 URI指向的一个数据处理 历程 ，那这个历程 生成的数据，在应答中以实体的情势 被返回，而不是将这个历程 的代码的返回。
　　如果HTTP包中含有If-ModifiedSince, If-Unmodified-Since, If-Match, If-None-Match, 或 If-Range等头字段，则GET也就变成了”条件GET“，即只有满足上述字段描绘的条件的实体才被取回，这样可以减少一些非必须 的网络传输，或者减少为获取某一资源的多次恳求 （如第一次反省 ，第二次下载）。（一般的涉猎 器，都有一个临时目录，用来缓存一些网页信息，当再次涉猎 某个页面的时候，只下载那些修正 过的内容，以加快涉猎 速度，就是这个道理。至于反省 ，则常用比GET更好的法子 HEAD来实现。）如果HTTP包中含有Range头字段，那么恳求 URI指定的实体中，只有抉择 领域条件的那部分才被取回来。（用过多线程下载工具的朋友，可能对比 容易了解这一点）
　　这个法子 的范例利用 ，用来从web服务器下载文档。HttpClient定义了一个类叫GetMethod来支撑 这个法子 ，用GetMethod类中getResponseBody, getResponseBodyAsStream 或 getResponseBodyAsString函数就可以取到应答包包体中的文档（如HTML页面）信息。这这三个函数 中，getResponseBodyAsStream通常是最好的法子 ，首要是因为它可以避免在处理 下载的文档之前缓存所有的下载的数据。

GetMethod get = new GetMethod("");
// 履行 法子 ，并处理 失败的恳求 .
...
InputStream in = get.getResponseBodyAsStream();
// 利用 输入流来处理 信息。
get.releaseConnection();

　　对GetMethod的最常见的不正确 的应用 ，是没有将整个 的应答主体的数据读出来。还有，必须 注意要手工明确 地将链接释放。

　　3、Head

　　HTTP的Head法子 ，与Get法子 完整 一致，唯一的区别 是服务器不能在应答包中包孕 主体(message-body)，而且必然不能包孕 主体。应用 这个法子 ，可以使得客户无需将资源下载回就可就以得到一些关于它的根基信息。这个法子 常用来反省 超链的可造访 性以及资源最近有没有被修正 。
　　HTTP的head法子 最范例的利用 ，是获取资源的根基信息。HttpClient定义了HeadMethod类支撑 这个法子 ，HeadMethod类与其它*Method类一样，用 getResponseHeaders()取回头部信息，而没有自己的特别 法子 。

HeadMethod head = new HeadMethod("");
// 履行 法子 ，并处理 失败的恳求 .
...
// 取回应答包的头字段信息.
Header[] headers = head.getResponseHeaders();
// 只取回最后修正 日期字段的信息.
String lastModified = head.getResponseHeader("last-modified").getValue();

　　4、Post

　　Post在英文有“派驻”的意思，HTTP法子 POST就是请求 服务器接管恳求 包中的实体，并将其作为恳求 URI的下属资源。从本色 上说，这意味着服务器要保存 这个实体信息，而且通常由服务器端的程序进行处理 。Post法子 的设计意图，是要以一种统一的法子 实现下列功效 ：
对已有的资源做评注

将信息发布 到BBS、消息 组、邮件列表，或类似 的文章组中

将一块数据，提交给数据处理 历程

通过追加操作，来扩张一个数据库
　　这些都操作期待 着在服务器端产生 必然的“副作用”，如修正 了数据库等。
　　HttpClient定义PostMethod类以支撑 该HTTP法子 ，在httpclient中，应用 post法子 有两个根基的步骤：为恳求 包筹办数据，然后读取服务器来的应答包的信息。通过调用 setRequestBody()函数，来为恳求 包供给 数据，它可以接管 三类参数：输入流、名值对数组或字符串。至于读取应答包需要 调用 getResponseBody* 那一系列的法子 ，与GET法子 处理 应答包的法子 雷同 。
　　常见问题是，没有将整个 应答读取（无论它对程序是否有用），或没有释放链接资源。

本文来自CSDN博客，转载请标明出处：

(责任编辑：admin)