java 6 新特性_Java SE 6 新特性: HTTP 增强(转)
Java
語言從誕生的那天起，就非常注重網(wǎng)絡(luò)編程方面的應(yīng)用。隨著互聯(lián)網(wǎng)應(yīng)用的飛速發(fā)展，Java 的基礎(chǔ)類庫也不斷地對(duì)網(wǎng)絡(luò)相關(guān)的 API
進(jìn)行加強(qiáng)和擴(kuò)展。在 Java SE 6 當(dāng)中，圍繞著 HTTP 協(xié)議出現(xiàn)了很多實(shí)用的新特性：NTLM 認(rèn)證提供了一種 Window
平臺(tái)下較為安全的認(rèn)證機(jī)制；JDK 當(dāng)中提供了一個(gè)輕量級(jí)的 HTTP 服務(wù)器；提供了較為完善的 HTTP Cookie 管理功能；更為實(shí)用的
NetworkInterface；DNS 域名的國際化支持等等。
不可避免，網(wǎng)絡(luò)中有很多資源是被安全域保護(hù)起來的。訪問這些資源需要對(duì)用戶的身份進(jìn)行認(rèn)證。下面是一個(gè)簡單的例子：
importjava.net.*;importjava.io.*;publicclassTest?{publicstaticvoidmain(String[]?args)throwsException?{
URL?url=newURL("http://PROTECTED.com");
URLConnection?connection=url.openConnection();
InputStream?in=connection.getInputStream();byte[]?data=newbyte[1024];while(in.read(data)>0)
{//do?something?for?data}
in.close();
}
}
當(dāng) Java 程序試圖從一個(gè)要求認(rèn)證的網(wǎng)站讀取信息的時(shí)候，也就是說，從聯(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è)問題，有兩種方法：
其一，是給 URLConnection 設(shè)定一個(gè)“Authentication”屬性：
String?credit=USERNAME+":"+PASSWORD;
String?encoding=newsun.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 類庫有沒有提供一個(gè)封裝了認(rèn)證細(xì)節(jié)，只需要給出用戶名/密碼的工具呢？
這就是我們要介紹的另一種方法，使用 java.net.Authentication 類。
每當(dāng)遇到網(wǎng)站需要認(rèn)證的時(shí)候，HttpURLConnection 都會(huì)向 Authentication 類詢問用戶名和密碼。
Authentication 類不會(huì)知道究竟用戶應(yīng)該使用哪個(gè) username/password 那么用戶如何向 Authentication 類提供自己的用戶名和密碼呢?
提供一個(gè)繼承于 Authentication 的類，實(shí)現(xiàn) getPasswordAuthentication 方法，在 PasswordAuthentication 中給出用戶名和密碼：
classDefaultAuthenticatorextendsAuthenticator?{publicPasswordAuthentication?getPasswordAuthentication?()?{returnnewPasswordAuthentication?("USER","PASSWORD".toCharArray());
}
}
然后，將它設(shè)為默認(rèn)的(全局)Authentication:
Authenticator.setDefault?(newDefaultAuthenticator());
那么，不同的網(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 的重要問題是認(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 的縮寫。早期的 SMB 協(xié)議在網(wǎng)絡(luò)上明文傳輸口令，這是很不安全的。微軟隨后提出了 WindowsNT 挑戰(zhàn)/響應(yīng)驗(yàn)證機(jī)制，即 NTLM。
NTLM 協(xié)議是這樣的：
客戶端首先將用戶的密碼加密成為密碼散列；
客戶端向服務(wù)器發(fā)送自己的用戶名，這個(gè)用戶名是用明文直接傳輸?shù)?#xff1b;
服務(wù)器產(chǎn)生一個(gè) 16 位的隨機(jī)數(shù)字發(fā)送給客戶端，作為一個(gè) challenge(挑戰(zhàn)) ；
客戶端用步驟1得到的密碼散列來加密這個(gè) challenge ，然后把這個(gè)返回給服務(wù)器；
服務(wù)器把用戶名、給客戶端的 challenge 、客戶端返回的 response 這三個(gè)東西，發(fā)送域控制器 ；
域控制器用這個(gè)用戶名在 SAM 密碼管理庫中找到這個(gè)用戶的密碼散列，然后使用這個(gè)密碼散列來加密 challenge；
域控制器比較兩次加密的 challenge ，如果一樣，那么認(rèn)證成功；
Java
6 以前的版本，是不支持 NTLM 認(rèn)證的。用戶若想使用 HttpConnection 連接到一個(gè)使用有 Windows
域保護(hù)的網(wǎng)站時(shí)，是無法通過 NTLM 認(rèn)證的。另一種方法，是用戶自己用 Socket 這樣的底層單元實(shí)現(xiàn)整個(gè)協(xié)議過程，這無疑是十分復(fù)雜的。
終于，Java 6 的 Authentication 類提供了對(duì) NTLM 的支持。使用十分方便，就像其他的認(rèn)證協(xié)議一樣：
classDefaultAuthenticatorextendsAuthenticator?{privatestaticString?username="username";privatestaticString?domain="domain";privatestaticString?password="password";publicPasswordAuthentication?getPasswordAuthentication()?{
String?usernamewithdomain=domain+"/"+username;return(newPasswordAuthentication(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 的。
Java 6 還提供了一個(gè)輕量級(jí)的純 Java Http 服務(wù)器的實(shí)現(xiàn)。下面是一個(gè)簡單的例子：
publicstaticvoidmain(String[]?args)throwsException{
HttpServerProvider?httpServerProvider=HttpServerProvider.provider();
InetSocketAddress?addr=newInetSocketAddress(7778);
HttpServer?httpServer=httpServerProvider.createHttpServer(addr,1);
httpServer.createContext("/myapp/",newMyHttpHandler());
httpServer.setExecutor(null);
httpServer.start();
System.out.println("started");
}staticclassMyHttpHandlerimplementsHttpHandler{publicvoidhandle(HttpExchange?httpExchange)throwsIOException?{
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 提供的實(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 來接收 http
請(qǐng)求并給出回答。
最后，在 HttpHandler 給出具體回答之前，一般先要返回一個(gè) Http head。這里使用 HttpExchange.sendResponseHeaders(int code, int length)。其中 code 是 Http 響應(yīng)的返回值，比如那個(gè)著名的 404。length 指的是 response 的長度，以字節(jié)為單位。
Cookie
是 Web 應(yīng)用當(dāng)中非常常用的一種技術(shù)， 用于儲(chǔ)存某些特定的用戶信息。雖然，我們不能把一些特別敏感的信息存放在 Cookie
里面，但是，Cookie 依然可以幫助我們儲(chǔ)存一些瑣碎的信息，幫助 Web
用戶在訪問網(wǎng)頁時(shí)獲得更好的體驗(yàn)，例如個(gè)人的搜索參數(shù)，顏色偏好以及上次的訪問時(shí)間等等。網(wǎng)絡(luò)程序開發(fā)者可以利用 Cookie
來創(chuàng)建有狀態(tài)的網(wǎng)絡(luò)會(huì)話(Stateful Session)。 Cookie 的應(yīng)用越來越普遍。在 Windows
里面，我們可以在“Documents And Settings”文件夾里面找到IE使用的 Cookie，假設(shè)用戶名為 admin，那么在
admin 文件夾的 Cookies 文件夾里面，我們可以看到名為“admin@(domain)”的一些文件，其中的 domain
就是表示創(chuàng)建這些 Cookie 文件的網(wǎng)絡(luò)域， 文件里面就儲(chǔ)存著用戶的一些信息。
JavaScript
等腳本語言對(duì) Cookie 有著很不錯(cuò)的支持。 .NET 里面也有相關(guān)的類來支持開發(fā)者對(duì) Cookie 的管理。 不過，在 Java SE 6
之前， Java一直都沒有提供 Cookie 管理的功能。在 Java SE 5 里面， java.net 包里面有一個(gè)
CookieHandler 抽象類，不過并沒有提供其他具體的實(shí)現(xiàn)。到了 Java SE 6， Cookie 相關(guān)的管理類在 Java
類庫里面才得到了實(shí)現(xiàn)。有了這些 Cookie 相關(guān)支持的類，Java 開發(fā)者可以在服務(wù)器端編程中很好的操作 Cookie， 更好的支持
HTTP 相關(guān)應(yīng)用，創(chuàng)建有狀態(tài)的 HTTP 會(huì)話。
用 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)，是否過期，網(wǎng)絡(luò)域，最大生命期等等信息。
用 CookiePolicy 規(guī)定 Cookie 接受策略
java.net.CookiePolicy
接口可以規(guī)定 Cookie 的接受策略。 其中唯一的方法用來判斷某一特定的 Cookie 是否能被某一特定的地址所接受。 這個(gè)類內(nèi)置了 3
個(gè)實(shí)現(xiàn)的子類。一個(gè)類接受所有的 Cookie，另一個(gè)則拒絕所有，還有一個(gè)類則接受所有來自原地址的 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 過期的時(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)：
圖 2. Cookie 管理類的關(guān)系
一個(gè) CookieManager 里面有一個(gè) CookieStore 和一個(gè) CookiePolicy，分別負(fù)責(zé)儲(chǔ)存 Cookie 和規(guī)定策略。用戶可以指定兩者，也可以使用系統(tǒng)默認(rèn)的 CookieManger。
例子
下面這個(gè)簡單的例子說明了 Cookie 相關(guān)的管理功能：
//創(chuàng)建一個(gè)默認(rèn)的?CookieManagerCookieManager?manager=newCookieManager();//將規(guī)則改掉，接受所有的?Cookiemanager.setCookiePolicy(CookiePolicy.ACCEPT_ALL);//保存這個(gè)定制的?CookieManagerCookieHandler.setDefault(manager);//接受?HTTP?請(qǐng)求的時(shí)候，得到和保存新的?CookieHttpCookie?cookie=newHttpCookie("(name)
","(value)
");
manager.getCookieStore().add(uri,?cookie);//使用?Cookie?的時(shí)候：//取出?CookieStoreCookieStore?store=manager.getCookieStore();//得到所有的?URIListuris=store.getURIs();for(URI?uri?:?uris)?{//篩選需要的?URI//得到屬于這個(gè)?URI?的所有?CookieListcookies=store.get(uri);for(HttpCookie?cookie?:?cookies)?{//取出了?Cookie}
}//或者，取出這個(gè)?CookieStore?里面的全部?Cookie//過期的?Cookie?將會(huì)被自動(dòng)刪除Listcookies=store.getCookies();for(HttpCookie?cookie?:?cookies)?{//取出了?Cookie}
從 Java SE 1.4 開始，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()
用來判斷網(wǎng)絡(luò)接口是否啟動(dòng)并運(yùn)行
public boolean isLoopback()
用來判斷網(wǎng)絡(luò)接口是否是環(huán)回接口(loopback)
public boolean isPointToPoint()
用來判斷網(wǎng)絡(luò)接口是否是點(diǎn)對(duì)點(diǎn)(P2P)網(wǎng)絡(luò)
public boolean supportsMulticast()
用來判斷網(wǎng)絡(luò)接口是否支持多播
public byte[] getHardwareAddress()
用來得到硬件地址(MAC)
public int getMTU()
用來得到最大傳輸單位(MTU，Maximum Transmission Unit)
public boolean isVirtual()
用來判斷網(wǎng)絡(luò)接口是否是虛擬接口
關(guān)于此工具類的具體信息，請(qǐng)參考 Java SE 6 相應(yīng)文檔(見 參考資源)。
在
最近的一些 RFC 文檔當(dāng)中，規(guī)定 DNS 服務(wù)器可以解析除開 ASCII 以外的編碼字符。有一個(gè)算法可以在這種情況下做 Unicode 與
ASCII 碼之間的轉(zhuǎn)換，實(shí)現(xiàn)域名的國際化。java.net.IDN 就是實(shí)現(xiàn)這個(gè)國際化域名轉(zhuǎn)換的新類，IDN
是“國際化域名”的縮寫(internationalized domain names)。這個(gè)類很簡單，主要包括 4 個(gè)靜態(tài)函數(shù)，做字符的轉(zhuǎn)換。
Java SE 6 有著很多 HTTP 相關(guān)的新特性，使得 Java SE 平臺(tái)本身對(duì)網(wǎng)絡(luò)編程，尤其是基于 HTTP 協(xié)議的因特網(wǎng)編程，有了更加強(qiáng)大的支持。
盡管千里冰封
依然擁有晴空
你我共同品味JAVA的濃香.
posted on 2007-11-14 09:12 千里冰封 閱讀(1584) 評(píng)論(0) ?編輯 ?收藏 所屬分類: 轉(zhuǎn)載文章
總結(jié)
以上是生活随笔為你收集整理的java 6 新特性_Java SE 6 新特性: HTTP 增强(转)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 交流电及整流滤波电路
- 下一篇： buck降压斩波电路