跳转到主要内容

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

这是您第一次登陆到 developerWorks,已经自动为您创建了您的概要文件。 选择您概要文件中可以公开的信息的信息(如姓名、国家/地区,以及公司),这些信息同时也会与您所发布的内容相关联。 您可以随时更新您的 IBM 账号。

所有提交的信息确保安全。

  • 关闭 [x]

当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

所有提交的信息确保安全。

  • 关闭 [x]

Java SE 6 新特性: HTTP 增强

李 夷磊, 软件工程师, EMC
李夷磊 ,目前就职于 IBM 中国开发中心 Harmony 开发团队,主要负责类库开发的技术工作,对 Java,OS 以及 system programming 有浓厚的兴趣。
胡 睿 (ruihu@cn.ibm.com), 软件工程师, EMC
胡睿
胡睿,目前就职于 IBM 中国开发中心 Harmony 开发团队。 主要负责类库开发的技术工作,对 J2SE、J2EE、C/C++、全球化技术、软件测试等有浓厚的兴趣。另外,他对历史、电影、音乐与羽毛球等也十分热爱。您可以通过ruihu@cn.ibm.com联系到他。

简介: 

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 方面的新特性。

查看本系列更多内容

发布日期: 2007 年 6 月 28 日
级别: 初级
访问情况 : 10196 次浏览
评论: 


概述

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)认证类型。

从上面的例子,我们可以看出,设定 Authentication 属性还是比较复杂的:用户必须了解认证方式的细节,才能将用户名 / 密码以一定的规范给出,然后用特定的编码方式加以编码。Java 类库有没有提供一个封装了认证细节,只需要给出用户名 / 密码的工具呢?

这就是我们要介绍的另一种方法,使用 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。

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 的。

轻量级 HTTP 服务器

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 管理特性

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 管理机制的结构:



    图 2. Cookie 管理类的关系
    图 2. 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 
     } 
    

其他新特性

NetworkInterface 的增强

从 Java SE 1.4 开始,JDK 当中出现了一个网络工具类 java.net.NetworkInterface,提供了一些网络的实用功能。 在 Java SE 6 当中,这个工具类得到了很大的加强,新增了很多实用的方法。例如:

  • public boolean isUp()

    用来判断网络接口是否启动并运行

  • public boolean isLoopback()

    用来判断网络接口是否是环回接口(loopback)

  • public boolean isPointToPoint()

    用来判断网络接口是否是点对点(P2P)网络

  • public boolean supportsMulticast()

    用来判断网络接口是否支持多播

  • public byte[] getHardwareAddress()

    用来得到硬件地址(MAC)

  • public int getMTU()

    用来得到最大传输单位(MTU,Maximum Transmission Unit)

  • public boolean isVirtual()

    用来判断网络接口是否是虚拟接口

关于此工具类的具体信息,请参考 Java SE 6 相应文档(见 参考资源)。

域名的国际化

在最近的一些 RFC 文档当中,规定 DNS 服务器可以解析除开 ASCII 以外的编码字符。有一个算法可以在这种情况下做 Unicode 与 ASCII 码之间的转换,实现域名的国际化。java.net.IDN 就是实现这个国际化域名转换的新类,IDN 是“国际化域名”的缩写(internationalized domain names)。这个类很简单,主要包括 4 个静态函数,做字符的转换。

结语

Java SE 6 有着很多 HTTP 相关的新特性,使得 Java SE 平台本身对网络编程,尤其是基于 HTTP 协议的因特网编程,有了更加强大的支持。


参考资料

作者简介

李夷磊 ,目前就职于 IBM 中国开发中心 Harmony 开发团队,主要负责类库开发的技术工作,对 Java,OS 以及 system programming 有浓厚的兴趣。

胡睿

胡睿,目前就职于 IBM 中国开发中心 Harmony 开发团队。 主要负责类库开发的技术工作,对 J2SE、J2EE、C/C++、全球化技术、软件测试等有浓厚的兴趣。另外,他对历史、电影、音乐与羽毛球等也十分热爱。您可以通过ruihu@cn.ibm.com联系到他。

关于报告滥用的帮助

报告滥用

谢谢! 此内容已经标识给管理员注意。


关于报告滥用的帮助

报告滥用

报告滥用提交失败。 请稍后重试。


developerWorks:登录


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 使用条款

 


当您初次登录到 developerWorks 时,将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人,但您可以随时修改这些信息的显示状态。您的姓名(除非选择隐藏)和昵称将和您在 developerWorks 发布的内容一同显示。

请选择您的昵称:

当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

(长度在 3 至 31 个字符之间)


单击提交则表示您同意developerWorks 的条款和条件。 使用条款.

 


为本文评分

评论

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Java technology
ArticleID=236636
ArticleTitle=Java SE 6 新特性: HTTP 增强
publish-date=06282007
author1-email=liyilei@cn.ibm.com
author1-email-cc=
author2-email=ruihu@cn.ibm.com
author2-email-cc=