cURL的作品，但在Apache的HttpComponents庫中的相同請求不？

我在這個小小的問題上已經把我的頭髮撕了幾天。希望這裏的某個人能夠發現我的錯誤（因爲我確信它在我的最後），並且告訴我一些關於如何補救的錯誤。如果我解釋失敗，請告訴我，我會盡量以更簡潔的方式重寫它。cURL的作品，但在Apache的HttpComponents庫中的相同請求不？

一點背景：作爲一個小側面項目的一部分，我已經寫了一個Java應用程序來監控通過在瀏覽器遊戲（僅供參考送出聊天和事件數據; Command & Conquer: Tiberium Alliances ）。可悲的是，關於他們的Web服務如何工作的文檔並不多，但我已經設法將一系列請求（基於觀察網絡流量和來自其他開發者發佈的代碼示例）拼湊在一起來處理登錄等。

一個特定的請求完全拒絕完成，並且Java在暫停30秒後拋出連接重置異常。以下是該特定請求的連接日誌。

2014/03/25 11:17:16:703 EDT [DEBUG] RequestAddCookies - CookieSpec selected: best-match 
2014/03/25 11:17:16:703 EDT [DEBUG] RequestAuthCache - Auth cache not set in the context 
2014/03/25 11:17:16:703 EDT [DEBUG] PoolingHttpClientConnectionManager - Connection request: [route: {s}->https://gamecdnorigin.alliances.commandandconquer.com:443][total kept alive: 1; route allocated: 0 of 2; total allocated: 1 of 20] 
2014/03/25 11:17:16:703 EDT [DEBUG] PoolingHttpClientConnectionManager - Connection leased: [id: 2][route: {s}->https://gamecdnorigin.alliances.commandandconquer.com:443][total kept alive: 1; route allocated: 1 of 2; total allocated: 2 of 20] 
2014/03/25 11:17:16:703 EDT [DEBUG] MainClientExec - Opening connection {s}->https://gamecdnorigin.alliances.commandandconquer.com:443 
2014/03/25 11:17:16:755 EDT [DEBUG] HttpClientConnectionOperator - Connecting to gamecdnorigin.alliances.commandandconquer.com/212.100.228.211:443 
*snip: 30 seconds of junk output* 
2014/03/25 11:18:16:992 EDT [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-2: Shutdown connection 
2014/03/25 11:18:16:992 EDT [DEBUG] MainClientExec - Connection discarded 
2014/03/25 11:18:16:993 EDT [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-2: Close connection 
2014/03/25 11:18:16:993 EDT [DEBUG] PoolingHttpClientConnectionManager - Connection released: [id: 2][route: {s}->https://gamecdnorigin.alliances.commandandconquer.com:443][total kept alive: 1; route allocated: 0 of 2; total allocated: 1 of 20] 
2014/03/25 11:18:16:993 EDT [INFO] RetryExec - I/O exception (java.net.SocketException) caught when processing request to {s}->https://gamecdnorigin.alliances.commandandconquer.com:443: Connection reset 
2014/03/25 11:18:16:993 EDT [DEBUG] RetryExec - Connection reset <java.net.SocketException: Connection reset>java.net.SocketException: Connection reset 
    at java.net.SocketInputStream.read(SocketInputStream.java:189) 
    at java.net.SocketInputStream.read(SocketInputStream.java:121) 
    at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) 
    at sun.security.ssl.InputRecord.read(InputRecord.java:503) 
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:954) 
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343) 
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371) 
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355) 
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:275) 
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:254) 
    at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:117) 
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) 
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) 
    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219) 
    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195) 
    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86) 
    at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) 
    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) 
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) 
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) 
*snip: lots of extra backtrace*

這是一個很大的，我知道：/

奇怪的部份是，運行使用PHP的捲曲完全相同的請求，工作得很好，我回去我會期望的信息。以下是發送失敗請求的Java代碼片段以及成功完成的PHP代碼片段。

的Java：通過PHP

public static boolean loadWorlds(Session session) { 
    HttpPost post = new HttpPost("https://gamecdnorigin.alliances.commandandconquer.com/Farm/Service.svc/ajaxEndpoint/GetOriginAccountInfo"); 
    HttpEntity entity = new StringEntity(String.format("{\"session\":\"%s\"}", session.getId()), ContentType.APPLICATION_JSON); 

    post.setHeader("Content-Type", "application/json; charset=utf-8"); 
    post.setHeader("X-Qooxdoo-Response-Type", "application/json"); 
    post.setHeader("Cache-Control", "no-cache"); 
    post.setHeader("Pragma", "no-cache"); 
    post.setEntity(entity); 

    try { 
     CloseableHttpResponse resp = ApiCommunicator.getHttpClient().execute(post); 

     System.out.println(EntityUtils.toString(resp.getEntity())); 
    } catch (Exception e) { 
     e.printStackTrace(); 
    } 

    return true; 
}

捲曲：

<?php 
    $cookie = 'cookies/' . md5($user) . '.txt'; 
    $data = array(
     'session' => 'hidden :P' 
    ); 

    $ch = curl_init(); 
    curl_setopt($ch, CURLOPT_URL, 'https://gamecdnorigin.alliances.commandandconquer.com/Farm/Service.svc/ajaxEndpoint/GetOriginAccountInfo'); 
    curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 2); 
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); 
    curl_setopt($ch, CURLOPT_HTTPHEADER, array(
     "Content-Type: application/json; charset=utf-8", 
     "Cache-Control: no-cache", 
     "Pragma: no-cache", 
     "X-Qooxdoo-Response-Type: application/json" 
    )); 
    curl_setopt($ch, CURLOPT_POST, true); 
    curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data)); 
    curl_setopt($ch, CURLOPT_COOKIEFILE, $cookie); 
    curl_setopt($ch, CURLOPT_COOKIEJAR, $cookie); 

    $result = curl_exec($ch); 
?>

在努力保持這個貼子儘可能短（因爲它已經文本的痛苦長壁）我稍微重寫了PHP以顯示$ cookie和$ data的值，因爲兩者都在腳本的執行中進一步設置。

任何幫助都將不勝感激。我不知道HttpComponents是否向請求添加或刪除標題數據（我從字面上剛剛開始學習庫2天前，當我拿起這個項目）cURL不會。如有必要，我可以發佈更多的代碼示例，因爲除了從服務器返回的個人登錄/會話信息之外，此項目中沒有任何內容真的是「祕密」的。此外，這是我第一次在這裏D：所以如果我沒有正確格式化的東西，或者如果我的代碼片段沒有突出顯示的權利讓我知道，我會盡我所能修復它:)

來源

2014-03-25 LartTyler

嘗試通過關閉您獲得的Closable實例來關閉底層連接。

CloseableHttpResponse resp = ApiCommunicator.getHttpClient().execute(post); 
try { 
     System.out.println(EntityUtils.toString(resp.getEntity())); 
    } catch (Exception e) { 
     e.printStackTrace(); 
    } 
    finally{ 
     resp.close(); 
    }

來源

2014-03-25 16:23:28

缺乏關閉不是問題。該特定請求永遠不會通過「連接到gamecdnorigin.alliances.commandandconquer.com/212.100.228.211:443」階段。我需要在那裏添加關閉聲明，是的，但我不認爲這是我現在的問題。 – LartTyler

我不熟悉捲曲，所以我會停下來，因爲我看不出如何比較兩個輸出。我會建議，但是使用一個工具，例如「wireshark」並記錄從curl和java所做的請求。然後，您可以比較它們以查看每個實際發送的內容。你可能會發現字符串中的差異等等，這也可能導致服務器拒絕來自java端的連接。 –

我一直在使用Wireshark來檢查由cURL請求和從Java發出的請求所做的連接，但兩者之間唯一的區別似乎是Java發送的結束於從服務器重置連接。現在，我沒有很多使用Wireshark的經驗（除了在本地IT小組實習一小段時間後），所以我很可能誤讀了輸出。有什麼建議麼？ – LartTyler

我會建議使用命令行選項-Djavax.net.debug = SSL作爲這個運行Java客戶端會給你更多的（但神祕的）洞察SSL握手。這應該說明底層連接問題，但可能需要一段時間才能瞭解此調試日誌將輸出的詳細信息。 http://www.smartjava.org/content/how-analyze-java-ssl-errors提供了一個非常好的，詳細的SSL握手討論。

你的HTTPClient沒有明確定義的SSLContext似乎是合理的。您可以探索使用其中一些選項來創建它。

SSLContext sslContext = SSLContexts.createDefault(); 
SSLConnectionSocketFactory sslSocketFactory = new SSLConnectionSocketFactory(sslContext, SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); 
CloseableHttpClient httpClient = HttpClients.custom().setSSLSocketFactory(sslSocketFactory).build();

請注意，您也可以從SSLContexts.custom定製的SSLContext（S）（），它允許您添加密鑰庫，信任，並指定使用TLS。

來源

2014-08-22 17:40:52

cURL的作品，但在Apache的HttpComponents庫中的相同請求不？

回答

相關問題