Java SE 6 新特性: HTTP 增强

　　2006 年底，Sun 公司发布了 Java Standard Edition 6(Java SE 6)的最终正式版，代号 Mustang(野马)。跟 Tiger(Java SE 5)相比，Mustang 在性能方面有了不错的提升。与 Tiger 在 API 库方面的大幅度加强相比，虽然 Mustang 在 API 库方面的新特性显得不太多，但是也提供了许多实用和方便的功能：在脚本，WebService，XML，编译器 API，数据库，JMX，网络和 Instrumentation 方面都有不错的新特性和功能加强。 本系列文章主要介绍 Java SE 6 在 API 库方面的部分新特性，通过一些例子和讲解，帮助开发者在编程实践当中更好的运用 Java SE 6，提高开发效率。

　　本文是系列文章的第二篇，介绍了Java SE 6 在 HTTP 方面的新特性。

      概述

　　Java 语言从诞生的那天起，就非常注重网络编程方面的应用。随着互联网应用的飞速发展，Java 的基础类库也不断地对网络相关的 API 进行加强和扩展。在 Java SE 6 当中，围绕着 HTTP 协议出现了很多实用的新特性：NTLM 认证提供了一种 Window 平台下较为安全的认证机制;JDK 当中提供了一个轻量级的 HTTP 服务器;提供了较为完善的 HTTP Cookie 治理功能;更为实用的 NetworkInterface;DNS 域名的国际化支持等等。

      NTLM 认证

　　不可避免，网络中有很多资源是被安全域保护起来的。访问这些资源需要对用户的身份进行认证。下面是一个简单的例子：

以下是引用片段： import java.net.*; import java.io.*; public class Test { public static void main(String[] args) throws Exception { URL url = new URL("http://PROTECTED.com"); URLConnection connection = url.openConnection(); InputStream in = connection.getInputStream(); byte[] data = new byte[1024]; while(in.read(data)>0) { //do something for data } in.close(); } }

　　当 Java 程序试图从一个要求认证的网站读取信息的时候，也就是说，从联系于 http://Protected.com 这个 URLConnection 的 InputStream 中 read 数据时，会引发 FileNotFoundException。尽管笔者认为，这个 Exception 的类型与实际错误发生的原因实在是相去甚远;但这个错误确实是由网络认证失败所导致的。

　　要解决这个问题，有两种方法：

　　其一，是给 URLConnection 设定一个“Authentication”属性：

以下是引用片段： String credit = USERNAME + ":" + PASSWORD; String encoding = new sun.misc.BASE64Encoder().encode (credit.getBytes()); connection.setRequestProperty ("Authorization", "Basic " + encoding);

　　这里假设 http://PROTECTED.COM 使用了基本(Basic)认证类型。

　　这就是我们要介绍的另一种方法，使用 java.net.Authentication 类。

　　每当碰到网站需要认证的时候，HttpURLConnection 都会向 Authentication 类询问用户名和密码。

　　Authentication 类不会知道究竟用户应该使用哪个 username/password 那么用户如何向 Authentication 类提供自己的用户名和密码呢?

　　提供一个继续于 Authentication 的类，实现 getPasswordAuthentication 方法，在 PasswordAuthentication 中给出用户名和密码：

以下是引用片段： class DefaultAuthenticator extends Authenticator { public PasswordAuthentication getPasswordAuthentication () { return new PasswordAuthentication ("USER", "PASSWORD".toCharArray()); } }

　　然后，将它设为默认的(全局)Authentication:

以下是引用片段： Authenticator.setDefault (new DefaultAuthenticator());

　　那么，不同的网站需要不同的用户名/密码又怎么办呢?

　　Authentication 提供了关于认证发起者的足够多的信息，让继续类根据这些信息进行判定，在 getPasswordAuthentication 方法中给出了不同的认证信息：

以下是引用片段： getRequestinGhost() getRequestingPort() getRequestingPrompt() getRequestingProtocol() getRequestingScheme() getRequestingURL() getRequestingSite() getRequestorType()

　　另一件关于 Authentication 的重要问题是认证类型。不同的认证类型需要 Authentication 执行不同的协议。至 Java SE 6.0 为止，Authentication 支持的认证方式有：

以下是引用片段： HTTP Basic authentication HTTP Digest authentication NTLM Http SPNEGO Negotiate Kerberos NTLM

　　NTLM 是 NT LAN Manager 的缩写。早期的 SMB 协议在网络上明文传输口令，这是很不安全的。微软随后提出了 WindowsNT 挑战/响应验证机制，即 NTLM。

　　NTLM 协议是这样的：

　　1.客户端首先将用户的密码加密成为密码散列;

　　2.客户端向服务器发送自己的用户名，这个用户名是用明文直接传输的;

　　3.服务器产生一个 16 位的随机数字发送给客户端，作为一个 challenge(挑战) ;

　　4.客户端用步骤1得到的密码散列来加密这个 challenge ，然后把这个返回给服务器;

　　5.服务器把用户名、给客户端的 challenge 、客户端返回的 response 这三个东西，发送域控制器 ;

　　6.域控制器用这个用户名在 SAM 密码治理库中找到这个用户的密码散列，然后使用这个密码散列来加密 challenge;

　　7.域控制器比较两次加密的 challenge ，假如一样，那么认证成功;

　　Java 6 以前的版本，是不支持 NTLM 认证的。用户若想使用 HttpConnection 连接到一个使用有 Windows 域保护的网站时，是无法通过 NTLM 认证的。另一种方法，是用户自己用 Socket 这样的底层单元实现整个协议过程，这无疑是十分复杂的。

　　终于，Java 6 的 Authentication 类提供了对 NTLM 的支持。使用十分方便，就像其他的认证协议一样：

以下是引用片段： class DefaultAuthenticator extends Authenticator { private static String username = "username "; private static String domain = "domain "; private static String password = "password "; public PasswordAuthentication getPasswordAuthentication() { String usernamewithdomain = domain + "/ "+username; return (new PasswordAuthentication(usernamewithdomain, password.toCharArray())); } }

　　这里，根据 Windows 域账户的命名规范，账户名为域名+”/”+域用户名。假如不想每生成 PasswordAuthentication 时，每次添加域名，可以设定一个系统变量名“http.auth.ntlm.domain“。

　　Java 6 中 Authentication 的另一个特性是认证协商。目前的服务器一般同时提供几种认证协议，根据客户端的不同能力，协商出一种认证方式。比如，IIS 服务器会同时提供 NTLM with kerberos 和 NTLM 两种认证方式，当客户端不支持 NTLM with kerberos 时，执行 NTLM 认证。

　　目前，Authentication 的默认协商次序是：

以下是引用片段： GSS/SPNEGO -> Digest -> NTLM -> Basic

　　那么 kerberos 的位置究竟在哪里呢?

　　事实上，GSS/SPNEGO 以 JAAS 为基石，而后者实际上就是使用 kerberos 的。

　　Java 6 还提供了一个轻量级的纯 Java Http 服务器的实现。下面是一个简单的例子：

以下是引用片段： public static void main(String[] args) throws Exception{ HttpServerProvider httpServerProvider = HttpServerProvider.provider(); InetSocketAddress addr = new InetSocketAddress(7778); HttpServer httpServer = httpServerProvider.createHttpServer(addr, 1); httpServer.createContext("/myapp/", new MyHttpHandler()); httpServer.setExecutor(null); httpServer.start(); System.out.println("started"); } static class MyHttpHandler implements HttpHandler{ public void handle(HttpExchange httpExchange) throws IOException { String response = "Hello world!"; httpExchange.sendResponseHeaders(200, response.length()); OutputStream out = httpExchange.getResponseBody(); out.write(response.getBytes()); out.close(); } }

　　然后，在浏览器中访问 http://localhost:7778/myapp/，我们得到：

      图一 浏览器显示

　　首先，HttpServer 是从 HttpProvider 处得到的，这里我们使用了 JDK 6 提供的实现。用户也可以自行实现一个 HttpProvider 和相应的 HttpServer 实现。

　　其次，HttpServer 是有上下文(context)的概念的。比如，http://localhost:7778/myapp/ 中“/myapp/”就是相对于 HttpServer Root 的上下文。对于每个上下文，都有一个 HttpHandler 来接收 http 请求并给出回答。

　　最后，在 HttpHandler 给出具体回答之前，一般先要返回一个 Http head。这里使用 HttpExchange.sendResponseHeaders(int code, int length)。其中 code 是 Http 响应的返回值，比如那个闻名的 404。length 指的是 response 的长度，以字节为单位。

　　Cookie 是 Web 应用当中非经常用的一种技术， 用于储存某些特定的用户信息。虽然，我们不能把一些非凡敏感的信息存放在 Cookie 里面，但是，Cookie 依然可以帮助我们储存一些琐碎的信息，帮助 Web 用户在访问网页时获得更好的体验，例如个人的搜索参数，颜色偏好以及上次的访问时间等等。网络程序开发者可以利用 Cookie 来创建有状态的网络会话(Stateful Session)。 Cookie 的应用越来越普遍。在 Windows 里面，我们可以在“Documents And Settings”文件夹里面找到IE使用的 Cookie，假设用户名为 admin，那么在 admin 文件夹的 Cookies 文件夹里面，我们可以看到名为“admin@(domain)”的一些文件，其中的 domain 就是表示创建这些 Cookie 文件的网络域， 文件里面就储存着用户的一些信息。

　　javascript 等脚本语言对 Cookie 有着很不错的支持。 .NET 里面也有相关的类来支持开发者对 Cookie 的治理。 不过，在 Java SE 6 之前， Java一直都没有提供 Cookie 治理的功能。在 Java SE 5 里面， java.net 包里面有一个 CookieHandler 抽象类，不过并没有提供其他具体的实现。到了 Java SE 6， Cookie 相关的治理类在 Java 类库里面才得到了实现。有了这些 Cookie 相关支持的类，Java 开发者可以在服务器端编程中很好的操作 Cookie， 更好的支持 HTTP 相关应用，创建有状态的 HTTP 会话。

　　·用 HttpCookie 代表 Cookie

　　java.net.HttpCookie 类是 Java SE 6 新增的一个表示 HTTP Cookie 的新类， 其对象可以表示 Cookie 的内容， 可以支持所有三种 Cookie 规范：

　　Netscape 草案

　　RFC 2109 - http://www.ietf.org/rfc/rfc2109.txt

　　RFC 2965 - http://www.ietf.org/rfc/rfc2965.txt

　　这个类储存了 Cookie 的名称，路径，值，协议版本号，是否过期，网络域，最大生命期等等信息。

　　·用 CookiePolicy 规定 Cookie 接受策略

　　java.net.CookiePolicy 接口可以规定 Cookie 的接受策略。 其中唯一的方法用来判定某一特定的 Cookie 是否能被某一特定的地址所接受。 这个类内置了 3 个实现的子类。一个类接受所有的 Cookie，另一个则拒绝所有，还有一个类则接受所有来自原地址的 Cookie。

　　·用CookieStore 储存 Cookie

　　java.net.CookieStore 接口负责储存和取出 Cookie。 当有 HTTP 请求的时候，它便储存那些被接受的 Cookie; 当有 HTTP 回应的时候，它便取出相应的 Cookie。 另外，当一个 Cookie 过期的时候，它还负责自动删去这个 Cookie。

　　用 CookieManger/CookieHandler 治理 Cookie

　　java.net.CookieManager 是整个 Cookie 治理机制的核心，它是 CookieHandler 的默认实现子类。下图显示了整个 HTTP Cookie 治理机制的结构：

　　一个 CookieManager 里面有一个 CookieStore 和一个 CookiePolicy，分别负责储存 Cookie 和规定策略。用户可以指定两者，也可以使用系统默认的 CookieManger。

　　例子

　　下面这个简单的例子说明了 Cookie 相关的治理功能：

以下是引用片段： // 创建一个默认的 CookieManager CookieManager manager = new CookieManager(); // 将规则改掉，接受所有的 Cookie manager.setCookiePolicy(CookiePolicy.ACCEPT_ALL); // 保存这个定制的 CookieManager CookieHandler.setDefault(manager); // 接受 HTTP 请求的时候，得到和保存新的 Cookie HttpCookie cookie = new HttpCookie("...(name)...","...(value)..."); manager.getCookieStore().add(uri, cookie); // 使用 Cookie 的时候： // 取出 CookieStore CookieStore store = manager.getCookieStore(); // 得到所有的 URI List<URI> uris = store.getURIs(); for (URI uri : uris) { // 筛选需要的 URI // 得到属于这个 URI 的所有 Cookie List<HttpCookie> cookies = store.get(uri); for (HttpCookie cookie : cookies) { // 取出了 Cookie } } // 或者，取出这个 CookieStore 里面的全部 Cookie // 过期的 Cookie 将会被自动删除 List<HttpCookie> cookies = store.getCookies(); for (HttpCookie cookie : cookies) { // 取出了 Cookie }