无线&移动互联网技术研发

原文出处--------http://hi.baidu.com/wader2006/blog/item/7e7b3a291f7801fd99250a91.html  

虽然用telnet这样的程序都可把页面取回来，但是在与web服务器的交互中，如果涉及cookie或https或ssl等内容，一般功能相对完备的http客户端还是非常必要的。IE或NetScape等浏览器确实不错，可是如果为实现持续互动而在程序调用浏览器，我个人认为其中的工作量还是不小的，这还没考虑版权问题。最好的办法，就是能有一个开源的包，能实现http客户端的功能，供我们开发的程序调用。httpclient就是这么一个包，我相信可能有比它的实现更好的，但目前我只关注这个。：）
　　下面是nogoop做的功能比较表：

　　对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)

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

3、取得源码 

　　编译：

4、使用HttpClient编程的基本步聚 

1. 创建 HttpClient 的一个实例.
2. 创建某个方法（DeleteMethod，EntityEnclosingMethod，ExpectContinueMethod，GetMethod，HeadMethod，MultipartPostMethod，OptionsMethod，PostMethod，PutMethod，TraceMethod）的一个实例，一般可用要目标URL为参数。
3. 让 HttpClient 执行这个方法.
4. 读取应答信息.
5. 释放连接.
6. 处理应答.

　　在执行方法的过程中，有两种异常，一种是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)可以通过下述方法打开.

　　在这种模式时，HttpClient会主动将basic认证应答信息传给服务器，即使在某种情况下服务器可能返回认证失败的应答，这样做主要是为了减少连接的建立。为使每个新建的 HttpState实例都实行抢先认证，可以如下设置系统属性。

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认证时出现错误。

1. 从HttpClientAPI的角度来看，NTLM与其它认证方式一样的工作，差别是需要提供'NTCredentials'实例而不是'UsernamePasswordCredentials'(其实，前者只是扩展了后者)
2. 对NTLM认证，访问空间是连接到的机器的域名，这对多域名主机会有一些麻烦.只有HttpClient连接中指定的域名才是认证用的域名。建议将realm设为null以使用默认的设置。
3. NTLM只是认证了一个连接而不是一请求，所以每当一个新的连接建立就要进行一次认证，且在认证的过程中保持连接是非常重要的。 因此，NTLM不能同时用于代理认证和服务器认证，也不能用于http1.0连接或服务器不支持持久连接的情况。

6、重定向

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

1. 301 永久移动. HttpStatus.SC_MOVED_PERMANENTLY
2. 302 临时移动. HttpStatus.SC_MOVED_TEMPORARILY
3. 303 See Other. HttpStatus.SC_SEE_OTHER
4. 307 临时重定向. HttpStatus.SC_TEMPORARY_REDIRECT

　　当收到简单的重定向时，程序应从HttpMethod对象中抽取新的URL并将其下载。另外,限制一下重定向次数是个好的主意，这可以避免递归循环。新的URL可以从头字段Location中抽取，如下：

特殊重定向：

1. 300 多重选择. HttpStatus.SC_MULTIPLE_CHOICES
2. 304 没有改动. HttpStatus.SC_NO T_MODIFIED
3. 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规范有：

1. Netscape cookie草案，是最早的cookie规范，基于rfc2109。尽管这个规范与rc2109有较大的差别，这样做可以与一些服务器兼容。
2. rfc2109，是w3c发布的第一个官方cookie规范。理论上讲，所有的服务器在处理cookie(版本1)时，都要遵循此规范，正因如此，HttpClient将其设为默认的规范。遗憾的是，这个规范太严格了，以致很多服务器不正确的实施了该规范或仍在作用Netscape规范。在这种情况下，应使用兼容规范。
3. 兼容性规范，设计用来兼容尽可能多的服务器，即使它们并没有遵循标准规范。当解析cookie出现问题时，应考虑采用兼容性规范。

　　 RFC2965规范暂时没有被HttpClient支持（在以后的版本为会加上），它定义了cookie版本2，并说明了版本1cookie的不足，RFC2965有意有久取代rfc2109.
　　在HttpClient中，有两种方法来指定cookie规范的使用，

1. HttpClient client = new HttpClient();
   client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
   这种方法设置的规范只对当前的HttpState有效，参数可取值CookiePolicy.COMPATIBILITY，CookiePolicy.NETSCAPE_DRAFT或CookiePolicy.RFC2109。
2. System.setProperty("apache.commons.httpclient.cookiespec", "COMPATIBILITY");
   此法指的规范，对以后每个新建立的HttpState对象都有效，参数可取值"COMPATIBILITY","NETSCAPE_DRAFT"或"RFC2109"。
   　　常有不能解析cookie的问题，但更换到兼容规范大都能解决。

9、使用HttpClient遇到问题怎么办? 

1. 用一个浏览器访问服务器，以确认服务器应答正常
2. 如果在使代理，关掉代理试试
3. 另找一个服务器来试试（如果运行着不同的服务器软件更好）
4. 检查代码是否按教程中讲的思路编写
5. 设置log级别为debug，找出问题出现的原因
6. 打开wiretrace，来追踪客户端与服务器的通信，以确实问题出现在什么地方
7. 用telnet或netcat手工将信息发送到服务器，适合于猜测已经找到了原因而进行试验时
8. 将netcat以监听方式运行，用作服务器以检查httpclient如何处理应答的。
9. 利用最新的httpclient试试，bug可能在最新的版本中修复了
10. 向邮件列表求帮助
11. 向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中定制SSL的步骤如下：

1. 提供了一个实现了org.apache.commons.httpclient.protocol.SecureProtocolSocketFactory接口的socket factory。这个 socket factory负责打一个到服务器的端口，使用标准的或第三方的SSL函数库，并进行象连接握手等初始化操作。通常情况下，这个初始化操作在端口被创建时自动进行的。
2. 实例化一个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("www.whatever.com", 443, myhttps);
   GetMethod httpget = new GetMethod("/");
   httpclient.executeMethod(httpget);
3. 通过调用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("https://www.whatever.com/");
   httpclient.executeMethod(httpget);

　　已知的限制和问题

1. 持续的SSL连接在Sun的低于1.4JVM上不能工作，这是由于JVM的bug造成。
2. 通过代理访问服务器时，非抢先认证（ Non-preemptive authentication）会失败，这是由于HttpClient的设计缺陷造成的，以后的版本中会修改。

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

1、httpclient的多线程处理

　　使用多线程的主要目的，是为了实现并行的下载。在httpclient运行的过程中，每个http协议的方法，使用一个HttpConnection实例。由于连接是一种有限的资源，每个连接在某一时刻只能供一个线程和方法使用，所以需要确保在需要时正确地分配连接。HttpClient采用了一种类似jdbc连接池的方法来管理连接，这个管理工作由 MultiThreadedHttpConnectionManager完成。

此是，client可以在多个线程中被用来执行多个方法。每次调用HttpClient.executeMethod() 方法，都会去链接管理器申请一个连接实例，申请成功这个链接实例被签出(checkout)，随之在链接使用完后必须归还管理器。管理器支持两个设置：

对每一个HttpClient.executeMethod须有一个method.releaseConnection()与之匹配.

12、HTTP方法

　　HttpClient支持的HTTP方法有8种，下面分述之。

　　1、Options

　　HTTP方法Options用来向服务器发送请求，希望获得针对由请求URL(request url)标志的资源在请求/应答的通信过程可以使用的功能选项。通过这个方法，客户端可以在采取具体行动之前，就可对某一资源决定采取什么动作和/或以及一些必要条件，或者了解服务器提供的功能。这个方法最典型的应用，就是用来获取服务器支持哪些HTTP方法。
　　HttpClient中有一个类叫OptionsMethod，来支持这个HTTP方法，利用这个类的getAllowedMethods方法，就可以很简单地实现上述的典型应用。

　　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的最常见的不正确的使用，是没有将全部的应答主体的数据读出来。还有，必须注意要手工明确地将链接释放。

　　3、Head

　　HTTP的Head方法，与Get方法完全一致，唯一的差别是服务器不能在应答包中包含主体(message-body)，而且一定不能包含主体。使用这个方法，可以使得客户无需将资源下载回就可就以得到一些关于它的基本信息。这个方法常用来检查超链的可访问性以及资源最近有没有被修改。
　　HTTP的head方法最典型的应用，是获取资源的基本信息。HttpClient定义了HeadMethod类支持这个方法，HeadMethod类与其它*Method类一样，用 getResponseHeaders()取回头部信息，而没有自己的特殊方法。

　　4、Post

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

1. 对已有的资源做评注
2. 将信息发布到BBS、新闻组、邮件列表，或类似的文章组中
3. 将一块数据，提交给数据处理进程
4. 通过追加操作，来扩展一个数据库

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