學習筆記--JDK中的URLConnection引數詳解
JDK中的URLConnection引數詳解
針對JDK中的URLConnection連線Servlet的問題,網上有雖然有所涉及,但是隻是說明了某一個或幾個問題，是以FAQ的方式來解決的，而且比較零散，現在對這個類的使用就本人在專案中的使用經驗做如下總結：1:> URL請求的類別:
分為二類,GET與POST請求。二者的區別在於：
a:) get請求可以獲取靜態頁面，也可以把引數放在URL字串後面，傳遞給servlet，
b:) post與get的不同之處在於post的引數不是放在URL字串裡面，而是放在http請求的正文內。
2:> URLConnection的物件問題:
URLConnection的物件,如下程式碼示例:
// 下面的index.jsp由<servlet-mapping>對映到
// 一個Servlet(com.quantanetwork.getClientDataServlet)
// 該Servlet的注意點下邊會提到
URL url =
new URL("http://localhost:8080/TestHttpURLConnectionPro/index.jsp");
URLConnection rulConnection = url.openConnection();
//
此處的urlConnection物件實際上是根據URL的
//
的子類HttpURLConnection,故此處最好將其轉化
//
為HttpURLConnection型別的物件,以便用到
HttpURLConnection httpUrlConnection = (HttpURLConnection) rulConnection;
3:> HttpURLConnection物件引數問題
//
設定是否向httpUrlConnection輸出，因為這個是post請求，引數要放在
//
http正文內，因此需要設為true, 預設情況下是false;
httpUrlConnection.setDoOutput(
true);
//
設定是否從httpUrlConnection讀入，預設情況下是true;
httpUrlConnection.setDoInput(
true);
//
Post 請求不能使用快取
httpUrlConnection.setUseCaches(
false);
//
設定傳送的內容型別是可序列化的java物件
//
(如果不設此項,在傳送序列化物件時,當WEB服務預設的不是這種型別時可能拋java.io.EOFException)
httpUrlConnection.setRequestProperty("Content-type", "application/x-java-serialized-object");
//
設定請求的方法為"POST"，預設是GET
httpUrlConnection.setRequestMethod("POST");
//
連線，從上述第2條中url.openConnection()至此的配置必須要在connect之前完成，
httpUrlConnection.connect();
4:> HttpURLConnection連線問題：
//
此處getOutputStream會隱含的進行connect(即：如同呼叫上面的connect()方法，
//
所以在開發中不呼叫上述的connect()也可以)。
OutputStream outStrm = httpUrlConnection.getOutputStream();
5:> HttpURLConnection寫資料與傳送資料問題：
//
現在通過輸出流物件構建物件輸出流物件，以實現輸出可序列化的物件。
ObjectOutputStream objOutputStrm =
new ObjectOutputStream(outStrm);
//
向物件輸出流寫出資料，這些資料將存到記憶體緩衝區中
objOutputStrm.writeObject(
new String("我是測試資料"));
//
重新整理物件輸出流，將任何位元組都寫入潛在的流中（些處為ObjectOutputStream）
objOutputStm.flush();
//
關閉流物件。此時，不能再向物件輸出流寫入任何資料，先前寫入的資料存在於記憶體緩衝區中,
//
在呼叫下邊的getInputStream()函式時才把準備好的http請求正式傳送到伺服器
objOutputStm.close();
//
呼叫HttpURLConnection連線物件的getInputStream()函式,
//
將記憶體緩衝區中封裝好的完整的HTTP請求電文傳送到服務端。
InputStream inStrm = httpConn.getInputStream();
//
<===注意，實際傳送請求的程式碼段就在這裡
//
上邊的httpConn.getInputStream()方法已呼叫,本次HTTP請求已結束,下邊向物件輸出流的輸出已無意義，
//
既使物件輸出流沒有呼叫close()方法，下邊的操作也不會向物件輸出流寫入任何資料.
//
因此，要重新發送資料時需要重新建立連線、重新設引數、重新建立流物件、重新寫資料、
//
重新發送資料(至於是否不用重新這些操作需要再研究)
objOutputStm.writeObject(
new String(""));
httpConn.getInputStream();
總結：a:) HttpURLConnection的connect()函式，實際上只是建立了一個與伺服器的tcp連線，並沒有實際傳送http請求。
無論是post還是get，http請求實際上直到HttpURLConnection的getInputStream()這個函式裡面才正式傳送出去。
b:) 在用POST方式傳送URL請求時，URL請求引數的設定順序是重中之重，
對connection物件的一切配置（那一堆set函式）
都必須要在connect()函式執行之前完成。而對outputStream的寫操作，又必須要在inputStream的讀操作之前。
這些順序實際上是由http請求的格式決定的。
如果inputStream讀操作在outputStream的寫操作之前，會丟擲例外：
java.net.ProtocolException: Cannot write output after reading input.......
c:) http請求實際上由兩部分組成，
一個是http頭，所有關於此次http請求的配置都在http頭裡面定義，
一個是正文content。
connect()函式會根據HttpURLConnection物件的配置值生成http頭部資訊，因此在呼叫connect函式之前，
就必須把所有的配置準備好。
d:) 在http頭後面緊跟著的是http請求的正文，正文的內容是通過outputStream流寫入的，
實際上outputStream不是一個網路流，充其量是個字串流，往裡面寫入的東西不會立即傳送到網路，
而是存在於記憶體緩衝區中，待outputStream流關閉時，根據輸入的內容生成http正文。
至此，http請求的東西已經全部準備就緒。在getInputStream()函式呼叫的時候，就會把準備好的http請求
正式傳送到伺服器了，然後返回一個輸入流，用於讀取伺服器對於此次http請求的返回資訊。由於http
請求在getInputStream的時候已經發送出去了（包括http頭和正文），因此在getInputStream()函式
之後對connection物件進行設定（對http頭的資訊進行修改）或者寫入outputStream（對正文進行修改）
都是沒有意義的了，執行這些操作會導致異常的發生。
6:> Servlet端的開發注意點：
a:) 對於客戶端傳送的POST型別的HTTP請求，Servlet必須實現doPost方法，而不能用doGet方法。
b:) 用HttpServletRequest的getInputStream()方法取得InputStream的物件，比如：
InputStream inStream = httpRequest.getInputStream();
現在呼叫inStream.available()（該方法用於“返回此輸入流下一個方法呼叫可以不受阻塞地
從此輸入流讀取（或跳過）的估計位元組數”）時，永遠都反回0。試圖使用此方法的返回值分配緩衝區，
以儲存此流所有資料的做法是不正確的。那麼，現在的解決辦法是
Servlet這一端用如下實現：
InputStream inStream = httpRequest.getInputStream();
ObjectInputStream objInStream = new ObjectInputStream(inStream);
Object obj = objInStream.readObject();
// 做後續的處理
// 。。。。。。
// 。。。 。。。
而客戶端，無論是否傳送實際資料都要寫入一個物件（那怕這個物件不用），如：
ObjectOutputStream objOutputStrm = new ObjectOutputStream(outStrm);
objOutputStrm.writeObject(new String("")); // 這裡傳送一個空資料
// 甚至可以發一個null物件，服務端取到後再做判斷處理。
objOutputStrm.writeObject(null);
objOutputStrm.flush();
objOutputStrm.close();
注意:上述在建立物件輸出流ObjectOutputStream時,如果將從HttpServletRequest取得的輸入流
(即:new ObjectOutputStream(outStrm)中的outStrm)包裝在BufferedOutputStream流裡面,
則必須有objOutputStrm.flush();這一句,以便將流資訊刷入緩衝輸出流.如下:
ObjectOutputStream objOutputStrm = new ObjectOutputStream(new BufferedOutputStream(outStrm));
objOutputStrm.writeObject(null);
objOutputStrm.flush(); // <======此處必須要有.
objOutputStrm.close();
HttpURLConnection是基於HTTP協議的，其底層通過socket通訊實現。如果不設定超時（timeout），在網路異常的情況下，可能會導致程式僵死而不繼續往下執行。可以通過以下兩個語句來設定相應的超時：
System.setProperty("sun.net.client.defaultConnectTimeout", 超時毫秒數字符串);
System.setProperty("sun.net.client.defaultReadTimeout", 超時毫秒數字符串);
其中： sun.net.client.defaultConnectTimeout：連線主機的超時時間（單位：毫秒）
sun.net.client.defaultReadTimeout：從主機讀取資料的超時時間（單位：毫秒）
例如：
System.setProperty("sun.net.client.defaultConnectTimeout", "30000");
System.setProperty("sun.net.client.defaultReadTime
Java中可以使用HttpURLConnection來請求WEB資源。
HttpURLConnection物件不能直接構造，需要通過URL.openConnection()來獲得HttpURLConnection物件，示例程式碼如下：
String szUrl = "http://www.ee2ee.com/";
URL url =
new URL(szUrl);
HttpURLConnection urlCon = (HttpURLConnection)url.openConnection();
HttpURLConnection是基於HTTP協議的，其底層通過socket通訊實現。如果不設定超時（timeout），在網路異常的情況下，可能會導致程式僵死而不繼續往下執行。可以通過以下兩個語句來設定相應的超時：
System.setProperty("sun.net.client.defaultConnectTimeout", 超時毫秒數字符串);
System.setProperty("sun.net.client.defaultReadTimeout", 超時毫秒數字符串);
其中： sun.net.client.defaultConnectTimeout：連線主機的超時時間（單位：毫秒）
sun.net.client.defaultReadTimeout：從主機讀取資料的超時時間（單位：毫秒）
例如：
System.setProperty("sun.net.client.defaultConnectTimeout", "30000");
System.setProperty("sun.net.client.defaultReadTimeout", "30000");
JDK 1.5以前的版本，只能通過設定這兩個系統屬性來控制網路超時。在1.5中，還可以使用HttpURLConnection的父類URLConnection的以下兩個方法：
setConnectTimeout：設定連線主機超時（單位：毫秒）
setReadTimeout：設定從主機讀取資料超時（單位：毫秒）
例如：
HttpURLConnection urlCon = (HttpURLConnection)url.openConnection();
urlCon.setConnectTimeout(30000);
urlCon.setReadTimeout(30000);
需要注意的是，筆者在JDK1.4.2環境下，發現在設定了defaultReadTimeout的情況下，如果發生網路超時，HttpURLConnection會自動重新提交一次請求，出現一次請求呼叫，請求伺服器兩次的問題（Trouble）。我認為這是JDK1.4.2的一個bug。在JDK1.5.0中，此問題已得到解決，不存在自動重發現象。out", "30000");