Java SE 6 新特性: HTTP增強(qiáng)
不可避免，網(wǎng)絡(luò)中有很多資源是被安全域保護(hù)起來(lái)的。訪問(wèn)這些資源需要對(duì)用戶的身份進(jìn)行認(rèn)證。下面是一個(gè)簡(jiǎn)單的例子：
| 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(); } } |
當(dāng) Java 程序試圖從一個(gè)要求認(rèn)證的網(wǎng)站讀取信息的時(shí)候，也就是說(shuō)，從聯(lián)系于 http://Protected.com 這個(gè) URLConnection 的 InputStream 中 read 數(shù)據(jù)時(shí)，會(huì)引發(fā) FileNotFoundException。盡管筆者認(rèn)為，這個(gè) Exception 的類型與實(shí)際錯(cuò)誤發(fā)生的原因?qū)嵲谑窍嗳ド踹h(yuǎn)；但這個(gè)錯(cuò)誤確實(shí)是由網(wǎng)絡(luò)認(rèn)證失敗所導(dǎo)致的。
要解決這個(gè)問(wèn)題，有兩種方法：
其一，是給 URLConnection 設(shè)定一個(gè)“Authentication”屬性：
| String credit = USERNAME + ":" + PASSWORD; String encoding = new sun.misc.BASE64Encoder().encode (credit.getBytes()); connection.setRequestProperty ("Authorization", "Basic " + encoding); |
這里假設(shè) http://PROTECTED.COM 使用了基本（Basic）認(rèn)證類型。
從上面的例子，我們可以看出，設(shè)定 Authentication 屬性還是比較復(fù)雜的：用戶必須了解認(rèn)證方式的細(xì)節(jié)，才能將用戶名/密碼以一定的規(guī)范給出，然后用特定的編碼方式加以編碼。Java 類庫(kù)有沒(méi)有提供一個(gè)封裝了認(rèn)證細(xì)節(jié)，只需要給出用戶名/密碼的工具呢？
這就是我們要介紹的另一種方法，使用 java.net.Authentication 類。
每當(dāng)遇到網(wǎng)站需要認(rèn)證的時(shí)候，HttpURLConnection 都會(huì)向 Authentication 類詢問(wèn)用戶名和密碼。
Authentication 類不會(huì)知道究竟用戶應(yīng)該使用哪個(gè) username/password 那么用戶如何向 Authentication 類提供自己的用戶名和密碼呢?
提供一個(gè)繼承于 Authentication 的類，實(shí)現(xiàn) getPasswordAuthentication 方法，在 PasswordAuthentication 中給出用戶名和密碼：
| class DefaultAuthenticator extends Authenticator { public PasswordAuthentication getPasswordAuthentication () { return new PasswordAuthentication ("USER", "PASSWORD".toCharArray()); } } |
然后，將它設(shè)為默認(rèn)的（全局）Authentication:
| Authenticator.setDefault (new DefaultAuthenticator()); |
那么，不同的網(wǎng)站需要不同的用戶名/密碼又怎么辦呢?
Authentication 提供了關(guān)于認(rèn)證發(fā)起者的足夠多的信息，讓繼承類根據(jù)這些信息進(jìn)行判斷，在 getPasswordAuthentication 方法中給出了不同的認(rèn)證信息：
| getRequestingHost() getRequestingPort() getRequestingPrompt() getRequestingProtocol() getRequestingScheme() getRequestingURL() getRequestingSite() getRequestorType() |
另一件關(guān)于 Authentication 的重要問(wèn)題是認(rèn)證類型。不同的認(rèn)證類型需要 Authentication 執(zhí)行不同的協(xié)議。至 Java SE 6.0 為止，Authentication 支持的認(rèn)證方式有：
| HTTP Basic authentication HTTP Digest authentication NTLM Http SPNEGO Negotiate Kerberos NTLM |
這里我們著重介紹 NTLM。
NTLM 是 NT LAN Manager 的縮寫(xiě)。早期的 SMB 協(xié)議在網(wǎng)絡(luò)上明文傳輸口令，這是很不安全的。微軟隨后提出了 WindowsNT 挑戰(zhàn)/響應(yīng)驗(yàn)證機(jī)制，即 NTLM。
NTLM 協(xié)議是這樣的：
·客戶端首先將用戶的密碼加密成為密碼散列；
·客戶端向服務(wù)器發(fā)送自己的用戶名，這個(gè)用戶名是用明文直接傳輸?shù)模?
·服務(wù)器產(chǎn)生一個(gè) 16 位的隨機(jī)數(shù)字發(fā)送給客戶端，作為一個(gè) challenge（挑戰(zhàn)） ；
·客戶端用步驟1得到的密碼散列來(lái)加密這個(gè) challenge ，然后把這個(gè)返回給服務(wù)器；
·服務(wù)器把用戶名、給客戶端的 challenge 、客戶端返回的 response 這三個(gè)東西，發(fā)送域控制器 ；
·域控制器用這個(gè)用戶名在 SAM 密碼管理庫(kù)中找到這個(gè)用戶的密碼散列，然后使用這個(gè)密碼散列來(lái)加密 challenge；
·域控制器比較兩次加密的 challenge ，如果一樣，那么認(rèn)證成功；
Java 6 以前的版本，是不支持 NTLM 認(rèn)證的。用戶若想使用 HttpConnection 連接到一個(gè)使用有 Windows 域保護(hù)的網(wǎng)站時(shí)，是無(wú)法通過(guò) NTLM 認(rèn)證的。另一種方法，是用戶自己用 Socket 這樣的底層單元實(shí)現(xiàn)整個(gè)協(xié)議過(guò)程，這無(wú)疑是十分復(fù)雜的。
終于，Java 6 的 Authentication 類提供了對(duì) NTLM 的支持。使用十分方便，就像其他的認(rèn)證協(xié)議一樣：
| 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())); } } |
這里，根據(jù) Windows 域賬戶的命名規(guī)范，賬戶名為域名+”/”+域用戶名。如果不想每生成 PasswordAuthentication 時(shí)，每次添加域名，可以設(shè)定一個(gè)系統(tǒng)變量名“http.auth.ntlm.domain“。
Java 6 中 Authentication 的另一個(gè)特性是認(rèn)證協(xié)商。目前的服務(wù)器一般同時(shí)提供幾種認(rèn)證協(xié)議，根據(jù)客戶端的不同能力，協(xié)商出一種認(rèn)證方式。比如，IIS 服務(wù)器會(huì)同時(shí)提供 NTLM with kerberos 和 NTLM 兩種認(rèn)證方式，當(dāng)客戶端不支持 NTLM with kerberos 時(shí)，執(zhí)行 NTLM 認(rèn)證。
目前，Authentication 的默認(rèn)協(xié)商次序是：
GSS/SPNEGO -> Digest -> NTLM -> Basic
那么 kerberos 的位置究竟在哪里呢?
事實(shí)上，GSS/SPNEGO 以 JAAS 為基石，而后者實(shí)際上就是使用 kerberos 的。
輕量級(jí) HTTP 服務(wù)器
Java SE 6 新特性中還提供了一個(gè)輕量級(jí)的純 Java Http 服務(wù)器的實(shí)現(xiàn)來(lái)對(duì)HTTP增強(qiáng)。下面是一個(gè)簡(jiǎn)單的例子：
| 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(); } } |
然后，在瀏覽器中訪問(wèn) http://localhost:7778/myapp/，我們得到：
|
|
首先，HttpServer 是從 HttpProvider 處得到的，這里我們使用了 JDK 6 提供的實(shí)現(xiàn)。用戶也可以自行實(shí)現(xiàn)一個(gè) HttpProvider 和相應(yīng)的 HttpServer 實(shí)現(xiàn)。
其次，HttpServer 是有上下文（context）的概念的。比如，http://localhost:7778/myapp/ 中“/myapp/”就是相對(duì)于 HttpServer Root 的上下文。對(duì)于每個(gè)上下文，都有一個(gè) HttpHandler 來(lái)接收 http 請(qǐng)求并給出回答。
***，在 HttpHandler 給出具體回答之前，一般先要返回一個(gè) Http head。這里使用 HttpExchange.sendResponseHeaders(int code, int length)。其中 code 是 Http 響應(yīng)的返回值，比如那個(gè)著名的 404。length 指的是 response 的長(zhǎng)度，以字節(jié)為單位。
Cookie 管理特性
Cookie 是 Web 應(yīng)用當(dāng)中非常常用的一種技術(shù)， 用于儲(chǔ)存某些特定的用戶信息。雖然，我們不能把一些特別敏感的信息存放在 Cookie 里面，但是，Cookie 依然可以幫助我們儲(chǔ)存一些瑣碎的信息，幫助 Web 用戶在訪問(wèn)網(wǎng)頁(yè)時(shí)獲得更好的體驗(yàn)，例如個(gè)人的搜索參數(shù)，顏色偏好以及上次的訪問(wèn)時(shí)間等等。網(wǎng)絡(luò)程序開(kāi)發(fā)者可以利用 Cookie 來(lái)創(chuàng)建有狀態(tài)的網(wǎng)絡(luò)會(huì)話（Stateful Session）。 Cookie 的應(yīng)用越來(lái)越普遍。在 Windows 里面，我們可以在“Documents And Settings”文件夾里面找到IE使用的 Cookie，假設(shè)用戶名為 admin，那么在 admin 文件夾的 Cookies 文件夾里面，我們可以看到名為“admin@(domain)”的一些文件，其中的 domain 就是表示創(chuàng)建這些 Cookie 文件的網(wǎng)絡(luò)域， 文件里面就儲(chǔ)存著用戶的一些信息。
JavaScript 等腳本語(yǔ)言對(duì) Cookie 有著很不錯(cuò)的支持。 .NET 里面也有相關(guān)的類來(lái)支持開(kāi)發(fā)者對(duì) Cookie 的管理。 不過(guò)，在 Java SE 6 之前， Java一直都沒(méi)有提供 Cookie 管理的功能。在 Java SE 5 里面， java.net 包里面有一個(gè) CookieHandler 抽象類，不過(guò)并沒(méi)有提供其他具體的實(shí)現(xiàn)。到了 Java SE 6新特性中， Cookie 相關(guān)的管理類在 Java 類庫(kù)里面才得到了實(shí)現(xiàn)。有了這些 Cookie 相關(guān)支持的類，Java 開(kāi)發(fā)者可以在服務(wù)器端編程中很好的操作 Cookie， 更好的支持 HTTP 相關(guān)應(yīng)用，創(chuàng)建有狀態(tài)的 HTTP 會(huì)話。這樣有效的進(jìn)行HTTP增強(qiáng)。
·用 HttpCookie 代表 Cookie
java.net.HttpCookie 類是 Java SE 6 新特性中，有一個(gè)表示 HTTP Cookie 的新類， 其對(duì)象可以表示 Cookie 的內(nèi)容， 可以支持所有三種 Cookie 規(guī)范：
Netscape 草案
RFC 2109 - http://www.ietf.org/rfc/rfc2109.txt
RFC 2965 - http://www.ietf.org/rfc/rfc2965.txt
這個(gè)類儲(chǔ)存了 Cookie 的名稱，路徑，值，協(xié)議版本號(hào)，是否過(guò)期，網(wǎng)絡(luò)域，***生命期等等信息。
·用 CookiePolicy 規(guī)定 Cookie 接受策略
java.net.CookiePolicy 接口可以規(guī)定 Cookie 的接受策略。 其中唯一的方法用來(lái)判斷某一特定的 Cookie 是否能被某一特定的地址所接受。 這個(gè)類內(nèi)置了 3 個(gè)實(shí)現(xiàn)的子類。一個(gè)類接受所有的 Cookie，另一個(gè)則拒絕所有，還有一個(gè)類則接受所有來(lái)自原地址的 Cookie。
·用CookieStore 儲(chǔ)存 Cookie
java.net.CookieStore 接口負(fù)責(zé)儲(chǔ)存和取出 Cookie。 當(dāng)有 HTTP 請(qǐng)求的時(shí)候，它便儲(chǔ)存那些被接受的 Cookie； 當(dāng)有 HTTP 回應(yīng)的時(shí)候，它便取出相應(yīng)的 Cookie。 另外，當(dāng)一個(gè) Cookie 過(guò)期的時(shí)候，它還負(fù)責(zé)自動(dòng)刪去這個(gè) Cookie。
·用 CookieManger/CookieHandler 管理 Cookie
java.net.CookieManager 是整個(gè) Cookie 管理機(jī)制的核心，它是 CookieHandler 的默認(rèn)實(shí)現(xiàn)子類。下圖顯示了整個(gè) HTTP Cookie 管理機(jī)制的結(jié)構(gòu)：
|
|
一個(gè) CookieManager 里面有一個(gè) CookieStore 和一個(gè) CookiePolicy，分別負(fù)責(zé)儲(chǔ)存 Cookie 和規(guī)定策略。用戶可以指定兩者，也可以使用系統(tǒng)默認(rèn)的 CookieManger。
例子
下面這個(gè)簡(jiǎn)單的例子說(shuō)明了 Cookie 相關(guān)的管理功能：
| // 創(chuàng)建一個(gè)默認(rèn)的 CookieManager CookieManager manager = new CookieManager(); // 將規(guī)則改掉，接受所有的 Cookie manager.setCookiePolicy(CookiePolicy.ACCEPT_ALL); // 保存這個(gè)定制的 CookieManager CookieHandler.setDefault(manager); // 接受 HTTP 請(qǐng)求的時(shí)候，得到和保存新的 Cookie HttpCookie cookie = new HttpCookie("...(name)...","...(value)..."); manager.getCookieStore().add(uri, cookie); // 使用 Cookie 的時(shí)候： // 取出 CookieStore CookieStore store = manager.getCookieStore(); // 得到所有的 URI List for (URI uri : uris) { // 篩選需要的 URI // 得到屬于這個(gè) URI 的所有 Cookie List for (HttpCookie cookie : cookies) { // 取出了 Cookie } } // 或者，取出這個(gè) CookieStore 里面的全部 Cookie // 過(guò)期的 Cookie 將會(huì)被自動(dòng)刪除 List for (HttpCookie cookie : cookies) { // 取出了 Cookie } |
其他新特性
·NetworkInterface 的增強(qiáng)
從 Java SE 1.4 開(kāi)始，JDK 當(dāng)中出現(xiàn)了一個(gè)網(wǎng)絡(luò)工具類 java.net.NetworkInterface，提供了一些網(wǎng)絡(luò)的實(shí)用功能。 在 Java SE 6 當(dāng)中，這個(gè)工具類得到了很大的加強(qiáng)，新增了很多實(shí)用的方法。例如：
public boolean isUp()
用來(lái)判斷網(wǎng)絡(luò)接口是否啟動(dòng)并運(yùn)行
public boolean isLoopback()
用來(lái)判斷網(wǎng)絡(luò)接口是否是環(huán)回接口（loopback）
public boolean isPointToPoint()
用來(lái)判斷網(wǎng)絡(luò)接口是否是點(diǎn)對(duì)點(diǎn)（P2P）網(wǎng)絡(luò)
public boolean supportsMulticast()
用來(lái)判斷網(wǎng)絡(luò)接口是否支持多播
public byte[] getHardwareAddress()
用來(lái)得到硬件地址（MAC）
public int getMTU()
用來(lái)得到***傳輸單位（MTU，Maximum Transmission Unit）
public boolean isVirtual()
用來(lái)判斷網(wǎng)絡(luò)接口是否是虛擬接口
關(guān)于此工具類的具體信息，請(qǐng)參考 Java SE 6 相應(yīng)文檔（見(jiàn) 參考資源）。
·域名的國(guó)際化
在最近的一些 RFC 文檔當(dāng)中，規(guī)定 DNS 服務(wù)器可以解析除開(kāi) ASCII 以外的編碼字符。有一個(gè)算法可以在這種情況下做 Unicode 與 ASCII 碼之間的轉(zhuǎn)換，實(shí)現(xiàn)域名的國(guó)際化。java.net.IDN 就是實(shí)現(xiàn)這個(gè)國(guó)際化域名轉(zhuǎn)換的新類，IDN 是“國(guó)際化域名”的縮寫(xiě)（internationalized domain names）。這個(gè)類很簡(jiǎn)單，主要包括 4 個(gè)靜態(tài)函數(shù)，做字符的轉(zhuǎn)換。
結(jié)束語(yǔ)
Java SE 6 有著很多 HTTP 相關(guān)的新特性，使得 Java SE 平臺(tái)本身對(duì)網(wǎng)絡(luò)編程，尤其是基于 HTTP 協(xié)議的因特網(wǎng)編程，有了更加強(qiáng)大的支持。
【編輯推薦】
