2010-11-01 117 views
0

我試圖用POST消息連接到服務器,要求服務器訂閱我。然後,服務器將保持http連接處於打開狀態,並以實時狀態向我發回異步消息,直到我請求取消訂閱或自行關閉連接。我無法從服務器讀取這些後續響應。下面的代碼連接到服務器併成功讀取第一個響應並將其打印到控制檯。問題在於,它始終以無限的方式讀取相同的響應(第一個響應)並將其打印到屏幕上。Java HttpURLConnection如何接收來自服務器的多個響應

有沒有人看到我在這裏搞亂了什麼?我正在嘗試僅監視來自服務器的下一個異步消息,並阻止它到來。此外,如果有人知道如何註冊以便在下一條消息異步顯示時得到通知,這樣我就不必阻止等待,甚至會更好。

public void HttpSubscription() 
{ 
    byte[] result = new byte[10240]; 

    try 
    { 
     /* Generate the hard coded request data */ 
     final StringBuffer soap = new StringBuffer(); 
     soap.append("<s:Envelope><s:Body><SoapTest1>thing1</SoapTest1></s:Body></s:Envelope>"); 

     // to make HTTP Post request with HttpURLConnection 
     URL url = new URL("http://192.168.1.110:80/services"); 
     HttpURLConnection conn = (HttpURLConnection)url.openConnection(); 

     // then set some properties and make a request 
     conn.setRequestMethod("POST"); 
     conn.setRequestProperty("Content-type", "text/xml; charset=utf-8"); 

     // Get a handle to the output stream 
     OutputStream OStream = conn.getOutputStream(); 

     // Write the soap data to the output stream 
     OStream.write(soap.toString().getBytes()); 

     InputStream ResponseStream = conn.getInputStream(); 
     while (true) 
     { 
      int len = ResponseStream.read(result); 
      String value = new String(result); 
      System.out.println(value); 
     } 
    } 
    catch (Exception e) 
    { 
     System.out.println(e); 
    } 

    return; 
} 

回答

1

你所描述的不是HTTP,它是別的。你可能能夠讓你的服務器來實現它,你可能不會。但期望HttpURLConnection能夠理解違反HTTP協議的內容有點多問,你不覺得嗎?

+0

服務器已經按照我說過的方式去做了。我沒有寫服務器,也沒有能力改變它的工作方式。我同意它不遵循Http規範中有關1請求和1響應的規定;但是你可以用這種方式使用Http。我有一個可以在c#中正常工作的客戶端。我的問題是可以JAVA支持這種訪問方式嗎?或者我將不得不下降到套接字級別並從頭開始實現?我寧願只使用Http類。 – 2010-11-03 01:53:44

+1

運氣不好,HttpURLConnection不會這樣做。你將不得不去到Socket層。 – EJP 2010-11-03 02:04:12

2

有點舊,但我決定在這裏糾正一些公然的錯誤信息。

答案指出HTTP請求的多個響應不符合HTTP規範是錯誤的!

RFC 2616

10狀態代碼定義

每個狀態代碼描述如下,包括該方法(一個或多個)它可以跟隨並在響應中所需的任何元信息的描述。

10.1信息性的1xx

這個類的狀態碼錶示臨時的響應,其中包括僅 的狀態行和可選的頭,並且由 空行終止。這種狀態 代碼沒有必要的標題。由於HTTP/1.0沒有定義任何1xx狀態碼,因此服務器必須不會向HTTP/1.0客戶端發送1xx響應,除了 實驗條件下。

客戶端必須準備接受一個或多個1xx狀態響應 之前的常規響應,即使客戶端不期望100 (續)狀態消息。意外的1xx狀態響應可能是用戶代理忽略的 。

相關問題